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ABSTRACT 


The  United  States  Navy  lacks  the  proper  and  efficient 
tools  to  evaluate/predict  the  performance  of  computer 
systems  during  the  early  design  phases  of  system 
development.  This  thesis  applies  state  of  the  art  techniques 
to  provide  a  methodology  that  can  assist  in  the 
evaluation/prediction  process  for  Naval  fire  control 
systems.  The  computer  system  evaluated  is  a  part  of  a 
modular  addition  to  existing  shipboard  gun  fire  control 
systems.  A  contract  for  the  Engineering  Development  (2D) 
phase  of  the  program  has  recently  been  awarded  to  industry. 
The  computer  system  architecture  is  evaluated  utilizing  a 
Petri-Net  simulation  which  is  best  suited  to  the  purpose  of 
concurrent  computer  system  performance  prediction.  The 
prediction  model,  described  herein,  accomplishes  the 
evaluation  with  the  results  being  utilized  to  recommend 
possible  performance  improvements  in  the  hardware  and 
software  to  the  U.S.Navy  Program  Office. 
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INTRODUCTION 


A.  BACKGROUND 

The  fire  control  system  evaluated,  the  SEAFIRE  program, 
is  presently  In  the  Engineering  Development  (ED)  phase  of 
the  weapon  system  development  process  with  system  deployment 
expected  some  time  during  the  mid  1980's.  A  Request  For 
Proposal  ( RFP)  for  the  design  of  the  system  was  released  to 
industry  and  was  responded  to  hy  a  number  of  contractor 
teams.  A  thorough  evaluation  of  these  proposals,  which 
included  technical,  management,  cost  and  schedule  factors, 
was  performed  over  a  ten  month  period  resulting  in  contract 
award  to  industry  during  1979.  The  contractor,  although 
provided  an  AN/UYK-20  computer  as  a  baseline  processor,  was 
not  prohibited  from  using  additional  imbedded  processors  to 
support/enhance  his  design.  The  AN/UYK-20,  being  a  standard 
Navy  computer,  was  required  for  use  in  the  SEAFIRE  system  at 
this  time.  The  Program  Office,  however,  has  plans  to  replace 
the  AN/UYK-20  with  a  modern  computer  prior  to  the  SEAFIRE 
fleet  introduction.  These  plans  though  will  only  be 
implemented  if  the  AN/UYK-20  is  replaced  as  one  of  the  Navy 
standard  computers  and  if  the  Naval  Material  Command  allows 
it  to  occur. 

The  computer  architecture,  as  designed  by  the 
contractor,  represents  an  untested  real  time  combat 
subsystem.  This  thesis  attempts  to  evaluate  the  SEAFIRE 
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computer  architecture  and  provide  a  meaningful  input  to  the 
0.  S.  Navy  SEAEIRE  program  office  (Naval  Sea  Systems 
Command)  as  to  its  predicted  performance. 


3.  APPROACH 

The  first  step  to  accomplishing  this  goal  was  to  become 
familiar  with  the  present  design  status  of  the  computer 
architecture  and  to  develop  liason  with  its  designer.  The 
present  level  of  the  design  drove  the  evaluation  to  a 
modular  configuration,  as  would  he  expected  at  this  point  in 
the  design  process.  A  determination  was  then  made  to 
establish  the  performance  measures  on  which  to  measure  or 
estimate  the  performance  of  the  system. 

The  next  step  was  to  research  a  number  of  available 
methodologies  for  computer  architecture  performance 
prediction  and  to  select  the  one  methodology  determined  best 
suited  for  this  project.  The  model  selected  was  designed  by 
L.A.  Cox,  based  on  work:  led  by  J.  Dennis  at  M.I.T.  and  other 
researchers.  This  model  was  developed  to  execute  on  a  non 
standard  CDC-7600  computer  system  and  thus  required 
considerable  effort  in  program  modification  to  enable  it  to 
run  on  the  PDP-11/50  minicomputer  at  NPS. 

The  remaining  work  consisted  of  developing  program 
representations  of  the  SEAEIRE  software  and  hardware  for  use 
in  the  simulator,  and  finally  in  the  analysis  of  the 
results.  A  number  of  assumptions,  which  were  reouired  due  to 
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a  lack  of  inf ormation,  are  denoted  throughout  this  thesis.  A 
listing  of  the  final  version  of  the  Petri-Net  simulator  is 
contained  in  Appendix  A. 
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II.  THE  COMPUTER  SYSTEM  ARCHITECT 

A.  INTRODUCTION 

How  does  the  computer  system  architect  cope  with  the 
rapid  pace  of  computer  technology?  His  capability  to 
describe  the  hardware  at  specified  levels  in  an  efficient, 
interactive  manner  that  provides  a  dynamic  atmosphere  during 
the  life  of  computer  design  may  be  the  key.  This  chapter 
deals  with  a  spectrum  of  design  techniques  that  assist  the 
archi tect . 

B.  COMPUTER  SYSTEM  ORGANIZATIONAL  LEVELS 

According  to  Doty  and  Liposki  (11)  Von  Neumann's  1946 
paper,  ’’Preliminary  Discussion  of  the  Logical  Design  of  an 
Electronic  Computing  Instrument"  is  fundamentally  one  of  the 
most  significant  papers  in  computer  architecture  written; 
principally  because  it  was  written  15  years  before  the  term 
was  coined  (Von  Neumann  claimed  no  ideas  but  was  merely  a 
focal  point  for  them).  This  paper  outlined  the  four 
principle  units  required  of  a  general  computing  system?  the 
control  unit,  the  data  operator,  the  memory,  and  the  input/ 
output  unit.  These  units  form  the  conceptual  basis  of  almost 
all  current  computers. 

ifhat  is  computer  architecture?  By  "computer 
architecture"  we  mean  the  abstract,  functional  description 
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of  a  computer  as  seen  by  a  machine-level  programmer,  that 
is,  everything  the  programmer  needs  to  know  to  write 
programs  that  run  effectively  on  the  computer  (i.e.,  the 
conceptual  structure  and  functional  behavior,  as  distinct 
from  the  organization  of  the  data  flow  and  controls,  the 
logical  design,  and  the  physical  implementation).  As  a 
result  of  the  changing  technologies  of  processors  and 
memories,  deficiencies  in  earlier  designs,  as  well  as 
innovations  in  networks  and  distributed  processing,  computer 
architecture  is  evolving  rapidly. 

In  addition  to  technology,  there  are  several  other  key 
factors  that  contribute  to  architectural  innovation?  most 
significant  are  increasingly  inexpensive  hardware  and  the 
rising  cost  of  software  (human  labor).  All  future  systems 
should  be  designed  with  consideration  of  these  and  other 
factors. 

A  good  system  can  be  defined  as  a  well-organized 
collection  of  components  chosen  to  meet  the  system  goal.  A 
modular  system  is  a  collection  of  these  component  modules. 
The  systems  are  the  largest  design  units,  and  subsystems  are 
convenient  intermediate-level  complexes  (18). 

One  system's  components  may  be  another's  systems,  in 
different  situations.  Therefore,  a  complex  system  design 
should  be  described  at  a  number  of  different  levels  which 
may  change  dynamically  as  the  design  proceeds  from  concept 
to  implementation. 
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1 .  Levels  of  Hardware  Design 


Bell 

and  Newell  (2) 

define  the 

levels 

in  the 

hierarchy  of 

digital  computer 

structures 

largely 

on  the 

basis  of  considering  the  different  activities  of  different 
technical  practitioners.  The  'institutional  positions'  of 
logic  designers  and  circuit  designers  are  used  as  evidence 
for  the  existence  of  distinct  levels.  Their  highest  level 
(the  PMS-Processor  Memory  System  level)  has  computers  as 
structures  and  processors,  memories  (storage)  etc.,  as 
components.  The  next,  or  programming  level,  sees  programs  as 
made  of  component  instructions,  operators,  etc.  The  three 
logic  design  levels  are  the: 

1)  Register  Transfer  Level  -  arithmetic  units  made  from 
registers,  controls,  data  operators; 

2)  Sequential  Switching  Circuit  Level  -  counters  made 
from  flipflops,  latches* 

3)  Combinatorial  Switching  Circuit  Level  -  encoders, 
selectors.  Iterative  nets  made  from  logic  gates. 

The  lowest  level  they  consider  is  the  circuit  level 
where  example  systems  (circuits)  are  amplifiers,  clocks  and 
gates  and  where  the  components  include  relays,  transistors, 
resistors,  diodes  and  delays.  The  essential  constraints  for 
the  notations  to  satisfy  are  ones  of  completeness, 
flexibility  and  brevity  (  high  informational  density)  (3). 

An  appropriate  criterion  might  be  to  identify  a  level  of 
design  with  a  design  description  (specification)  then: 
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* A  system  level  ...  is  characterized  by  a  distinct 
specification  for  representing  the  system  (that  is,  the 
components  modes  of  combination  and  laws  of  behavior).  These 
distinct  languages  reflect  special  properties  of  the  types 
of  components  and  of  the  way  they  combine  .  .  .  The  fact 
that  the  languages  are  highly  distinct  makes  it  possible  to 
be  confident  about  the  existence  of  different  levels  (2) 

This  method  of  identifying  the  various  levels  of  system 
design  allows  one  to  identify  the  most  recently  emerged 
levels,  but  it  leads  to  a  significant  difficulty.  Whenever 
it  is  difficult  to  decide  whether  two  languages  are  highly 
distinct,  it  is  also  difficult  to  decide  whether  they  define 
different  levels.  Thus  it  seems  as  though  there  are  no 
effective  procedures,  even  in  principle,  for  counting  the 
number  of  distinct  levels  of  system  design.  The  number  of 
levels,  and  thus  the  extent  or  depth  of  the  levels,  are 
difficult  to  precisely  determine. 

This  view  introduces  a  new  notion:  the  span  (depth)  of  a 
level  is  commensurate  with  the  short  term  comprehension  of  a 
human  being.  That  is,  one  historical  reason  for  designing  a 
large  system  in  successive  stages  has  been  that  the  human 
designer  has  a  certain  limit  to  the  range  of  detailed 
consideration  which  he  can  instantaneously  handle 
effectively  (although  Cray/Amhdahl  developed  computers 
individually).  If  the  design  process  is  to  be  automated,  it 
might  be  initially  done  in  smaller  steps  than  humans 
currently  handle  (for  the  machines  are  notoriously  inept  at 
handling  the  intuitive  associations  which  a  designer 
employs).  The  number  and  span  of  the  design  steps  has  always 
been  difficult  to  precisely  determine  and  we  should  expect 
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them  to  continue  to  change  in  the  future  (18).  It  is 
important  to  remember  that  all  our  experience  to  date  shows 
that  design  automation  cannot  rely  too  much  on  artificial 
methods;  the  human  has  to  stay  involved. 

The  design  specification  is  the  hey  to  the  definition  of 
a  level.  The  language  defines  the  level;  is  the  tool  for 
designing  at  that  level;  expresses  the  components  and 
systems  of  the  level;  and  provides  the  documentation  for 
design  at  that  level.  The  lowest-level,  irreducible  units  of 
a  design  are  the  primitives  (words)  of  the  language;  the 
system  structures  designed  at  that  level  are  the  sentences 
of  the  language.  Preparing  a  design  at  a  given  level  means 
writing  a  statement  in  the  language  of  the  level.  The 
process  of  designing  an  entire  system  becomes  a  process  of 
carefully  translating  statements  in  one  higher-level 
language  to  successively  lower  levels. 


*  ' 


mm 
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C.  COMPUTER  HARDWARE  DESCRIPTION  LANGUAGES 

Computer  hardware  description  languages  (CHDL's)  can  he 
defined  as  languages  for  describing,  documenting, 
simulating,  and  synthesizing  digital  systems  with  the  aid  of 
a  computer  (23).  A  CHDL  can  be  used  to  describe  the  logic 
gates,  the  sequential  machines,  and  the  functional  modules, 
along  with  their  interconnection  and  their  control,  in  a 
variation  of  a  programming  language  tuned  to  the  overall 
needs  of  describing  hardware. 

1.  Design  Automation 

Just  as  software  designers  use  high-level  languages  to 
express  algorithms  in  terms  of  language  statements,  so 
digital  hardware  designers  are  beginning  to  use  hardware 
description  languages  to  describe  the  digital  systems  they 
want  to  design  (24). 

The  task  of  designing  a  digital  hardware  system  can  be 
considered  as  consisting  of  the  following  steps: 

1)  The  generation  of  a  system  diagram  from  the 
specifications  of  the  system  to  be  designed. 

2)  The  production  of  detailed  logic  diagrams  for  each 
subsystem. 

3)  The  partitioning  of  the  logic  diagram  into  general 
units . 
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4)  The  assignment  of  integrated  circuit  chips  for 
implementing  each  unit. 

5)  The  placing  of  chips  on  logic  cards  and  of  cards  on 
boards,  and 

6)  The  interconnecting  of  the  chips. 

7)  The  testing  of  the  integrated  circuit  boards. 

Computers  have  been  widely  used  for  aiding  steps  4  to  7. 

A  total  design  automation  system  requires  that  steps  l,to  6 
be  automated.  CHDL's  can  be  used  for  aiding  system  and  logic 
design  as  well  as  partitioning  a  digital  system.  A  designer 
can  use  a  CHDL  to  express  his  design  and  leave  the  exacting, 
tedious,  uninteresting  details  to  a  computer  (23). 

The  process  of  automated  logic  design  may  consist  of 
the  following  steps: 

1)  A  designer  expresses  his  design  in  a  CHDL  by  writing 
a  program. 

2)  A  hardware  compiler  (translator)  checks  the  syntax, 
consistency,  etc.  of  the  language  statements  and  reports  the 
errors  to  the  designer  for  correction.  After  the  errors  are 
corrected,  the  translator  produces  a  data  base  to  be  used  by 
the  system  simulator  and  the  logic  synthesizer. 

3)  The  system  simulator  models  the  design  at  the  system 
level.  This  will  save  the  large  amount  of  computing  time 
used  for  simulating  everything  at  the  detailed  gate  level. 
If  the  system  performance  is  unsatisfactory,  the  design 
language  statements  are  modified.  If  the  performance  is 
satisfactory,  the  next  step  is  taken. 
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4)  The  logic  synthesizer  (a  program)  uses  the  data  base 


produced  by  the  translator,  accepts  the  types  and 
constraints  of  logic  components,  and  produces  a  logic 
diagram. 

Since  a  CHDL  constitutes  the  input  to  the  design 
automation  process,  it  plays  an  important  role  in  the  task 
of  achieving  automated  logic  and  system  design. 

2.  Digital  Hardware  Languages  Under  Development 

A  number  of  digital  hardware  languages  exist  today  and 
are  in  use  by  industry  as  well  government  sources.  One  of 
the  most  recent  uses  in  the  military  was  for  the  selection 
of  the  Computer  Family  Architecture  ( CFA)  (1,20).  This  was  a 
Joint  DOD  effort  aimed  at  providing  defense  systems 
developers  with  a  software  compatible  family  of  military 
computers  at  varied  levels  of  performance  that  have 
extensive  systems/support  hardware.  One  facet  of  the 
selection  process  was  that  the  measurements  and  tests  of 
hardware  candidates  were  made,  not  on  the  various  computers 
as  physical  objects,  but  on  their  formal  descriptions 
expressed  in  IS?L  (Instruction  Set  Processor  Language)  (2). 

This  was  the  first  time  that  the  architectures  of 
commercially  viable  computers  were  described  in  a  formal 
language,  the  description  compiled,  and  then  used  to  drive  a 
simulator,  executing  benchmarks  and  diagnostic  machine 
language  programs.  A  valid  sign  for  future  users  is  that  it 
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was  generally  accepted  toy  industry,  military  and  government. 

Vhat  other  methods  have  toeen  developed  since  the  atoove? 
The  remainder  of  this  section  covers  several  of  the  efforts 
presently  toeing  developed  as  a  result  of  the  Working  Group 
of  the  Conference  on  Computer  Hardware  Eescription 
Languages. 

a.  Consensus  Language  (CONLAN) 

CONLAN  is  a  consensus  hardware  description  language 
capable  of  representing  hardware  at  several  distinct  levels 
of  detail  (15).  The  range  of  language  levels  suggests  a 
family  of  languages  that  share  a  common  basic  syntax  and  are 
rooted  in  a  common  semantic  base. 

Guidelines  laid  down  for  the  language  follow: 

A.  CCNLAN  must  support  design,  description, 

/ 

and  simulation  of  at  least  the  following  classes  of  systems: 
gate  networks,  register  networks,  processors,  memories, 
processor  systems.  Each  class  has  toeen  fully  defined. 

B.  Any  system  may  toe  displayed  via  either  (a)  a 
network  structure  description  or  (to)  a  behavior  description. 

C.  CONLAN  is  to  service: 

1.  Computer  architects  and  logic  designers 
for  purposes  of  trade-off  exploration  and 
optimization,  design  verification,  and 
design  documentation. 

2.  Systems,  micro,  and  applications  program- 
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3.  Electronics  production  engineers. 

4.  Maintenance  engineers. 

0.  CONLAN  syntax  and  semantics  must  support: 

1.  Well-defined  descriptions 

2.  Machine  parsing,  interpretation  and 
simulation  with  error  detection  (strong 
typing  has  been  adopted) 

3.  Comprehension  of  complex  system  structure 
and  function 

4.  Division  of  design  efforts 

5.  Control  over  the  level  of  abstraction  at 
which  subsystems  are  described. 

6.  Simulation  control 

E.  CONLAN  will  be  evaluated  in  terms  of 
benchmarks  such  as:  standard  function  declarations,  time 
operator  declarations,  integrated  circuit  descriptions  (long 
list,  including  microprocessors),  design  descriptions 
(another  long  list  including  a  multiprocessor  system). 

The  details  of  CONLAN  (i.e.  BNE  grammer,  etc.)  are 
contained  in  (15).  Since  CONLAN  is  still  under  development, 
additional  information  is  available  only  from  the  working 
committee  which  is  developing  the  language. 

b.  Digital  Design  Language  Translator  (DDLTRN) 

Today,  the  greater  complexity  of  systems,  the  desire  for 


short  design  cycles  and  error-free  designs,  and  the  use  of 
array  logic  all  suggest  the  need  for  machine  assistance  in 
the  logic  design  activity  (8).  DDL  Is  a  block  oriented, 
statement  register  transfer  language  for  the  description  of 
digital  hardware.  DDLTRN  is  a  program  that  translates  a  DDL 
description  of  a  digital  system  to  Boolean  equations  and 
register  transfer  statements  suitable  for  driving  a 
companion  simulator  program  DDLSIM  (6,9).  DDLTRN  is  written 
in  the  IFTRAN  (a  structured  FORTRAN)  language  (16). 
Translation  consists  of  replacing  the  syntax  of  more 
abstract  language  constructs  with  more  explicit  syntax, 
yeilding  Boolean  equations  and  IF-THFN  conditioned  register 
transfer  statements. 

As  mentioned  earlier,  DDLSIM  is  a  program  for  simulating 
digital  systems  described  using  DDL  (7).  DDLSIM  does  very 
extensive  error  checking  of  described  systems,  simulation 
control  cards,  (same  system  with  different  data  sets  and/or 
parameters),  and  the  simulation  process  itself.  DDLSIM 
permits  multiple  simulation  runs  within  one  Job  in  order  to 
either  verify  the  system  design  or  study  its  behaviors  under 
different  conditions. 

DDLTRN/SIM  and  CONLAN  are  two  examples  of  the  growing 
number  of  design/automation  aids  available  today.  These 
CHDLs  put  the  the  architecture  community  in  the  position  to 
explore  and  develop  needed  design  automation  tools.  Since 
Dietmeyer  is  a  member  of  the  above  committee,  it  would  be 
expected  that  many  of  his  ideas  will  be  incorporated  into. 
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or  provide  the  basic  groundwork  for  future  efforts. 

D.  INTEGRATED  CIRCUIT  (IC)  DESIGN 


Ev 

*ince 

integrated  circuit 

designers  began 

to 

put 

thousands 

of 

transistors  onto  a 

single 

chip,  the 

cost 

,  in 

terms  of 

human 

labor,  required  to 

lay  out 

the  circuit 

has 

been  extremely  high.  Although  hardware  has  reached  a  point 
of  being  considerably  cheaper  than  software,  the  Department 
of  Defense  (DOD)  requirements  for  special  purpose,  limited 
market  chips  has  seen  its  time.  The  need  for  good  design 
automation  in  the  area  of  integrated  circuit  layout  is 
severe.  What  is  needed,  and  what  is  evolving,  are  design 
techniques  which  free  the  designer  from  the  tedious  aspects 
of  IC  design  and  allow  him  to  concentrate  on  the  more 
creative  and  necessarily  human  side  of  the  design  process. 

Using  traditional  methods,  large  scale  integrated 
circuit  lay  out  is  a  tedious,  time  consuming  and  error-prone 
process.  For  commercial  use,  where  literally  millions  of 
identical  chips  are  sold  each  year,  the  cost  to  do  this  has 
not  been  a  problem.  But  for  the  DOD  it  is  becoming  an 
increasingly  significant  problem;  especially  since  the  DOD 
market  for  ICs  comprises  only  about  7%  of  the  total  IC 
market  and  because  environmental  and  other  constraints  are 
becoming  more  severe  (16).  The  overall  goal  of  an  IC  design 
is  to  pack  as  much  circuity  as  possible  into  the  smallest 
possible  amount  of  "chip  real-estate" ( IC  density). 
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therefore,  higher  production  yields  may  he  obtained. 

1 .  The  Problem  and  the  Proposed  Solution 

At  present,  when  a  company  designs  large  scale 
systems,  there  are  often  delays  of  months  or  even  years  in 
the  development  of  a  prototype  IC  and  the  price  for  a  single 
chip  ranges  from  one  quarter  to  half  a  million  dollars,  the 
DOD  is  forced  to  revert  to  using  older  technology.  This, 
coupled  with  the  typical  eight  to  fourteen  year  system 
development  cycle  of  large  computer  systems  (examples 
include  AEGIS,  TACEIRE  and  CDC  STAR  100),  has  created  quite 
a  military  dilema.  Adi  to  these  problems  the  stringent 
requirements  for  MIL-SPEC  qualification,  fault-tolerance, 
built-in  test,  high  clock  rates,  and  the  use  of  advanced 
design  concepts  for  affordability,  causes  the  required  chips 
not  be  ready  for  several  years  and  when  available  are 
extremely  high  in  cost  to  the  user. 

A  new  DOD  (Tri-Service)  program  known  as  Very  High  Speed 
Integrated  Circuits  (VHSICs)  began  at  the  start  of  FT  79  and 
is  a  six  year  effort  initially  budgeted  for  in  excess  of 
$200  million  dollars.  Program  goals  require  a  processing 
throughput  capability  for  computers  of  between  100  to  1000 
times  greater  than  presently  exists. 

The  overall  purpose  of  the  DOD  program  is  to: 

.  Advance  introduction  of  VHSIC  into  military  systems 
by  at  least  five  years  ahead  of  present  projections 
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.  Focus  industry  attention  on  DOD  requirements  through 
the  establishment  of  distinct  goals  and  funding  infusion 

.  Make  the  latest  state-of-the-art  devices  available 
for  military  use  in  advance  of  commercial  exploitation, 
thereby  reversing  the  present  two  to  five  year  lag  between 
commercial  development  and  military  availability 

.  Advance  IC  technology  beyond  the  limits  of  optical 
litho-  graphy  to  submicron  dimensions 

.  Replace  over  fifty  or  more  present  ICs  with  one  IC, 
thereby  providing  at  least  a  ten-fold  reduction  in  the  size, 
weight,  power  consumption  and  failure  rate  with  accompanying 
savings  in  both  initial  and  life  cycle  costs  of  present 
military  computer  processing  systems. 

.  Provide  ICs  with  100  times  the  processing  throughput 
capability  of  present  ICs  (16). 

By  meeting  the  above  stated  goals,  the  DOD  expects  to 
achieve  affordable  chips,  reduce  potential  supply  and 
logistics  problems  and  maximize  system  reliability.  The 
improved  architectural  and  design  concepts  should  result  in 
a  limited  chip  set  with  broad  applicability  to  military 
systems . 


2 .  Can  the  Computer  Architect  Exploit  this  Advance? 


Despite  these  advances  that  semiconductor  technology 
has  created,  the  question  arises  as  to  whether  the  computer 
architect  can  exploit  these  with  proven  design  methods  of 


his  own.  A  number  of  approaches  have  been  actively  pursued 
over  the  last  few  years  (see  previous  section).  However, 
there  are  not  currently  the  languages,  operating  systems  and 
design  methods  needed  to  effectively  employ  the  new  LSI 
devices  which  can  now  be  produced.  We  would  like  to  be 
limited  only  by  economic  factors,  not  technical  or 
theoretical  factors.  A  hope  is  that  a  new  dimension  for  the 
architecture  of  computer  systems  will  emerge  from  these 
design  methods  so  that  LSI  design  methodology  can  be  used 
effectively.  There  is  a  need  to  proceed  slowly  and  rather 
cautiously  and  to  introduce  somewhat  more  general  purpose 
description  languages  selectively. 

The  military  system  cannot  afford  these  time  delays  and 
much  effort  is  being  pursued  to  shorten  this  cycle  and  to 
obtain  industry  input  earlier.  A  major  directive.  Office  of 
Management  and  Budget  Directive  0MB  A:109  (17),  has  as  a 
major  goal,  industry  involvement  in  system  development 
earlier  in  the  conceptual  development  phase.  This  thrust, 
combined  with  the  availability  of  the  tools  discussed  in 
this  section  on  design  automation  and  those  to  be  covered  on 
architecture  evaluation  could  be  implemented  as  Concept 
Development  Phase  evaluation  techniques.  The  impact  would  be 
to  provide  state-of-the-art  computer  designs  at  lower  costs 
with  the  added  effect  of  shortening  the  entire 
development/procurement  cycle. 
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E.  SUMMABY 

This  section  has  provided  the  basis  to  understand 
computer  architecture  as  viewed  by  different  practitioners 
and  how  methods  are  being  developed  to  assist  in  early 
design  phases.  These  techniques  can  assist  the  DOD  in 
realixing  better  structured  hardware  and  to  accomplish  the 
tasks  reauired. 

The  next  section  further  defines  the  methodology  phases 
of  architecture  evaluation  used  to  enhance  the  automated 
design  techniques  covered. 
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A.  INTRODUCTION 

Computer  performance  evaluation  attempts  to  provide  a 
methodology  for  examining  the  adequacy  of  a  computer  system 
as  it  serves  or  will  serve  the  needs  of  its  users.  In  this 
context,  performance  may  be  interpreted  as  the  technical 
equivalent  of  the  notion  of  value  to  the  user.  In  other 
words,  the  performance  evaluation  activities  can  be  regarded 
as  those  technical  activities  whose  purpose  is  the 
assessment  of  performance  (how  well  the  system  works)  (12). 
This  chapter  discusses  different  levels  of  performance 
evaluation. 

B.  PURPOSES  OF  PERFORMANCE  EVALUATION 

In  general,  there  are  three  major  motivations  for 
performance  evaluation:  selection  evaluation,  performance 
prediction  and  performance  monitoring.  These  purposes  can  be 
classified  along  several  dimensions  according  to  their 
specific  objectives.  As  with  many  other  system  evaluation 
techniques,  these  classifications  are  only  convenient  ways 
of  organizing  a  repertoire  of  knowledge  in  to  a  framework 
which  can  be  more  easily  understood.  The  dividing  lines 
between  categories  are  somewhat  unclear,  but  are  utilized 
for  lack  of  a  better  method. 
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One  of  the  most  frequent  reasons  for  initiating  an 
evaluation  is  to  include  performance  as  a  "decision 
criteria”  in  computer  system  or  digital  electronics  system 
decisions  for  a  specified  operational  requirement.  The 
section  on  SEAFIRE  provides  a  description  of  such  a  system 
along  with  an  overview  of  the  original  evaluation  guidelines 
for  procurement  of  the  system.  It  should  he  recognized  that 
the  computer  system  was  only  a  subsystem  in  the  context  of 
the  SEAFIRE  hardware,  which  in  turn  was  but  a  single  factor 
in  the  total  weapon  system  procurement  (cost,  management, 
etc.  were  also  weighted  as  portions  of  system  value).  Each 
competitive  contractor  teams  proposal  may  bave  contained  one 
or  more  superior  subsystems,  but  were  judged  to  have  fallen 
short  in  many  other  areas.  For  example,  one  of  the  losing 
contractors  may  have  had  a  better  computer  subsystem,  but 
poorer  subsystems  in  the  other  areas.  Additionally,  his 
management  approach  or  cost  proposal  may  not  have  been  as 
good  as  the  winners'.  Therefore,  the  weapon  system  design 
selected  may  not  necessarily  provide  the  U.S  Navy  with  the 
"best"  computer  architecture  available,  but  the  overall 
system  approach  is  probably  the  soundest  and  the  most  cost 
effective  for  the  Navy. 


In  general,  selection  problems  may  be  classified  into 


the  following  categories  (12) 


a.  Processing  mode  selection 

b.  Vendor  selection 


c.  Installation  Selection 

d.  System  Component  Selection 

e.  Application  Program  Selection 
A  definition  of  each  category  is  not  provided  since  the 
content  is  clear. 

2.  Performance  Projection 

i 

I 

; 

This  evaluation  technique  may  be  the  least  frequently 
used.  The  problem  here  is  to  estimate  the  performance  of  a 
system  not  yet  in  existance  (in  some  state  of  design).  Thus, 
the  evaluation  is  oriented  toward  a  new  system  design,  both 
hardware  and  software.  The  evaluation  technique  pursued  in 
this  research  is  encompassed  within  this  category.  The 
performance  evaluation  of  algorithms  run  on  a  particular 
computer  architecture  is  mostly  concerned  with  performance 
prediction  and  is  restricted,  in  general,  to  some  form  of 
computer  modeling  or  simulation.  In  section  V  a  method  of 
conceptually  representing  computer  systems  by  use  of  a 
concurrent  control  system  model  is  explained.  This  method 
forms  the  basis  for  the  performance  prediction  system 
developed  by  Cox  (4)  and  modified  for  use  here. 
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3.  Performance  Monitoring 

Cnee  a  system  is  operational,  monitoring  provides 
data  on  the  actual  performance  of  the  system.  The 
performance  statistics  that  may  he  obtained  while  executing 
test  programs  aid  in  future  equipment  procurement  decisions 
and  are  employed  by  the  system  user  for  system  tuning?  in 
forecasting  the  Impact  of  changes  in  the  system  (either  in 
reconfiguring  the  hardware  or  in  improving  executed  software 
modules) .  The  lmuact  of  future  technology  and  computer 
architecture  will  greatly  affect  performance  monitoring  at 
all  levels  of  the  computer  system.  Internal  and  external 
instrumentation  will  provide  data  accessible  to  the 
performance  evaluator.  A  distinction  should  be  understood 
here  between  performance  monitoring  (continuous)  and  an 
evaluation  study.  Continuous  monitoring  is  usually  performed 
for  a  substantial  portion  of  the  lifetime  of  the  existing, 
running  system.  Its  objective  is  to  keep  the  system's 
performance  under  observation  in  order  to  detect  performance 
problems  as  soon  as  they  arise.  An  evaluation  study  is 
generally  much  more  limited  in  time  and  is  usually  triggered 
by  the  identification  of  a  performance  problem  or  the 
suspicion  of  its  presence.  The  following  sections  delineate 
the  evaluation  aspects  at  various  hardware  levels. 
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a.  At  the  Chip  Level 

With  the  trend  to  large  scale  circuit  integration, 
performance  evaluation  through  hardware  instrumentation  is 
becoming  less  flexible.  The  number  of  leads  remain  constant 
or  decrease  while  the  number  of  functions  increase  with  the 
consequence  of  fewer  test  points  per  function  being 
available.  Since  the  cost  per  gate  has  reduced  by  a  factor 
of  100  over  the  last  ten  years,  it  is  now  economically 
feasible  to  devote  some  of  the  circuitry  in  these  chips  to 
auxiliary  functions  such  as  performance  monitoring.  This 
will  provide  built-in  data  analysis  without  the  addition  of 
any  hardware. 

b.  At  the  CP-I/0  Level 

At  this  level  the  large  -  scale  integrated  circuit 
chips  will  be  interconnected  in  various  ways  to  implement 
the  hardware  instrumentation.  Chips  such  as  microprocessors 
will  be  used  to  do  the  actual  work  in  this  area.  As  with  the 
previous  level,  lack  of  test  points  is  a  major  problem; 
microprogramming  causes  an  elimination  of  some  probe  points. 
Also,  more  test  points  are  lost  due  to  the  trend  towards 
eliminating  peripheral  channels.  Costs  can  be  reduced  by 
integrating  device  control  units  into  the  processor  and 
transferring  information  as  serial  bit  streams. 
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c.  At  the  System  Level 


At  this  level,  built-in  hardware  monitors  may 
provide  additional  assistance.  The  performance  statistics 
collected  hy  the  associated  hardware/software  can  he  time 
correlated  through  the  use  of  other  microprocessors.  The 
result  is  two  fold:  first  to  reduce  the  overhead  of  whatever 
software  instrumentation  is  still  required,  and  second  to 
eliminate  the  need  for  external  monitoring  devices.  The 
important  advance  at  this  level  is  that  performance  data 
will  he  stored  under  the  system's  database  management  system 
which  will  allow  for  on-line  display  of  performance 
monitoring  data.  The  data  is  therefore  available  for  on-line 
input  to  various  scheduling  algorithms  used  to  "fine  tune” 
the  system  dynamically.  A  major  draw-back  to  this  method  may 
be  that  the  evaluation  schemes  will  have  difficulty  in 
dealing  with  the  virtual  environment  of  present  and  future 
systems.  An  additional  way  would  be  the  tendency  to  less 
secure  systems  because  of  the  required  critical  parameters 
associated  with  the  performance  evaluation  schemes. 

d.  At  the  Network  Level 

Distributed  processing  is  the  functional 
distribution  and  cooperative  processing  of  user  applications 
among  multiple,  separately  located  computer  systems  of  the 
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same  and/or  different  size  and  characteristics.  The 
decreasing  cost  of  hardware  coupled  with  the  increasing 
performance  of  distributed  systems  offers  some  advantages  to 
performance  evaluation  at  this  level.  Performance  data  can 
he  collected  locally  at  each  site  and  transmitted  to  a 
central  cite  for  evaluation  and  will  provide  a  baseline  for 
network  tuning.  From  a  global  viewpoint  though,  more  factors 
must  be  taken  into  account  to  assure  that  suboptimization 
does  not  occur. 

C.  SUMMAPT 

This  chapter  has  provided  a  partial  outline  of 
performance  evaluation  techniques  used  for  computer 
evaluation.  Other  specific  techniques  such  as  benchmark, 
kernel,  analytical  model,  synthetic  programs,  etc.  are 
available  but  not  discussed  here.  A  thorough  discussion  is 
provided  in  reference  4.  These  areas  are  selection 
evaluation,  performance  prediction  and  performance 
monitoring.  The  DOD  requires  a  more  defined  approach  to  all 
these  areas  but  is  most  lacking  in  performance  prediction 
techniques. 

The  next  section  describes  a  predictive  method  which 
will  be  applied  in  this  thesis. 
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.  SEAFIRE  ( ELECTRO-OPTICAL  FIRE  CONTROL  SUBSYSTEM ) 

A.  INTRODUCTION 

This  section  provides  an  overall  description  of  the 
SEAFIRE  Program  and  outlines  its  intended  capabilities. 
SEAFIRE  is  presently  in  the  Engineering  Development  (ED) 
phase  of  the  weapon  system  development  process  with  system 
deployment  expected  sometime  during  the  mid  1980's.  A 
Request  for  Proposal  was  released  to  industry  and  was 
responded  to  by  a  number  of  contractor  teams.  A  thorough 
evaluation  of  these  proposals,  which  included  technical, 
management,  cost  and  schedule  factors,  was  performed  over  a 
ten  month  period  resulting  in  contract  award  to  industry 
during  1979.  The  computer  subsystem  section  of  the  RFP  is 
more  formally  described  and  the  computer  architecture 
response  to  this  section  is  described  at  the  component 
level . 

B.  SEAFIRE  DESCRIPTION 

1.  .Subsystem  Definition 

SEAFIRE  is  an  electro-optical  fire  control  subsystem 
modular  addition  to  shipboard  gun  fire  control  systems 
(GFCS).  This  addition  will  allow  control  of  the  guns  and 
gunfire  by  the  GFCS  when  ship's  sensors  can  designate 


34 


certain  targets  to  SEAFIRE  for  which  an  electro-optical 
sensor  is  effective.  SEAFIRE  will  also  allow  uninterrupted 
operation  of  GFCSs  when  the  GFCS  sensors  are  ineffective 
because  of  performance  degradation  or  are  incapacitated  by 
equipment  failure,  casualty  or  tactical  limitations.  SEAFIRE 
shall  consist  of  an  optical  director  (above  deck)  and 
control,  test  and  display  units.  As  a  subsystem  integrated 
with  a  GFCS,  SEAFIRE  will  perform  the  following  functions 
against  Surface  Major  Combatants,  shore 
vehicles/installations,  surface  coastal  defense  craft  and 
river  patrol  craft(22): 

a.  Target  Detection-SEA FIRE  will  provide  the 
GFCS  with  day  and  night,  passive  electro-optical  imaging  for 
detection,  manual  and  automatic  angle  tracking,  and  active 
laser  rangefinding.  SEAFIRE  will  be  capable  of  performing 
these  operations  against  sea,  surface  and  shore-based 
targets  which  can  be  engaged  by  the  GFCS  during  electronic 
countermeasures  (ECM),  electro-optical  countermeasures 
(EOCM )  and  Emission  Control  (EMCON)  conditions. 

b.  Target  illumination  -  Once  SEAFIRE  has 
established  track  of  a  target,  SEAFIRE  will  be  capable  of 
providing  laser  target  illumination  for  laser-guided 
ordinance. 

c.  Other  fire  control  functions  -  SEAFIRE  will 
be  capable  of  tracking  reference  points  (landmarks,  buoys, 
etc.)  to  provide  navigation  data  to  the  GFCS  for  indirect  or 
offset  firing.  SEAFIRE  shall  be  capable  of  sharing  its  line 
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of  sight  (LOS)  to  the  LOS  of  the  GFCS  radars  for  target 
identification  and  check  sighting. 

d.  Ancillary  Functions  -  When  not  employed  as  a 
target  tracking  sensor  for  fire  control,  the  inherent 
capabilities  of  SEAFIRE  will  provide  ancillary  functions 
including,  hut  not  limited  to:  detection  of  chemical  agent 
clouds,  and  aiding  in  navigation,  station  keeping,  friendly 
operations,  surveillance,  intelligence  collection,  swimmer 
detection  and  underway  replenishment. 

In  addition,  SEAFIRE  will  he  capable  of  being  configured 
as  a  SEAFIRE  independent  GFCS  for  applications  aboard  ships 
on  which  no  other  GFCS  exists.  As  a  SEAFIRE  independent 
GFCS,  SEAFIRE  should  be  capable  of  performing,  in  addition 
to  a,  b,  c,  and  d  above,  all  functions  necessary  to  engage 
and  direct  gunfire  against  all  trackable  targets.  These 
functions  will  include,  but  not  be  limited  to:  direct 
acceptance  of  tactical  information,  interface  with  ship's 
stable  reference,  generation  of  gun  orders  and  interface 
with  gun  mounts. 
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SEAFIRE  will  be  comprised  of  a  director,  passive 
imaging  sensors,  laser  transmitter  and  receiver,  as  well  as 
support,  display,  and  control  devices.  SEAFIRE  controls  and 
display  will  be  integrated  into  the  consoles  in  the  MARK  86 
and  92  GFCS  applications.  The  controls  and  display  in  the 
MAPK  63  GFCS  application  will  be  configured  as  a  draper  of 
the  AN/SPG-53  radar  console.  SEAFIRE  will  have  an 
independent  console  in  the  SEAFIRE  independent  GFCS.  The 
following  major  component  list  represents  the  SEAFIRE 
baseline(21) : 

Director 

Laser  Rangef inder/Illuminator  (LR/I) 

Thermal  Imaging  Sensor  (TIS) 

Television  Sensor  (TVS) 

Computer,  Computer  Program,  and  Related  Equipment 

Maintenance  Panel 

Interconnecting  Cables 

Remote  Video  Displays 

Support  and  Test  Equipment 

Console 

Automtic  Video  Traclter  (AVT) 

Interface  Module 

Video  Character  Generator 


Video  Processor 


Real  Time  Clock 


SEAFIRE  is  depicted  in  the  functional  block  diagram  of 
Figure  1 . 

3.  SEAFIRE  Operational  and  Organizational  Concepts 

SEAFIRE  will  he  used  in  conjunction  with  the  MARI 
86,  68  (digital),  92  and  SEAFIRE  independent  GFCSs  with 
ship's  interface  being  provided  through  the  GFCS,  except  in 
the  SEAFIRE  independent  GFCS.  In  all  applications,  SEAFIRE 
mode  structure  and  controls  should  he  designed  to  minimize 
operator  work  load.  The  following  list  represents  some 
SEAFIRE  operational  concepts. 

a.  For  engagements  In  which  the  fire  control 
radars  can  provide  adeauate  track  da*a,  SEAFIRE  may  he  used 
predominantly  in  D3SIGNATI0N/SLAVE  for  check-sighting, 
threat  evaluation,  spotting  corrections  for  fall  of  shot, 
and  kill/damage  assessment. 

h.  For  engagements  in  which  the  fire  control 
radars  have  degraded  performance  due  to  ECM  or  clutter, 
SEAFIRE  will  provide  independent  target  tracking  data.  The 
fire  control  operator  can  then  select  the  sensor  which  is 
providing  the  best  track  data. 

c.  In  the  event  of  a  detection/track  function  or 
equipment  failure  of  the  GFCS  sensor(s),  SEAFIRE  will 
provide  a  total  casualty  capability  for  the  GFCS, 
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allowing  continued  gun  and  gunfire  control  by  providing 
target  tracking  data.  This  will  be  accomplished  by  using  the 
GFCS  displays  and  controls,  where  practical,  and  the  GFCS 
computer  to  perform  the  gun  control  functions  such  as 
ballistics,  ammo  select,  fuze  function  and  code  set,  signal 
data  transmission  and  mount  status. 

d.  Under  EMCON,  the  SEAFIRE  passive  imaging 

k 

sensors  may  be  used  in  horizon  search,  or  to  evaluate 
contacts  detected  by  the  ship's  other  passive  sensors.  If 
tactics  permit  limited  emissions,  the  passive  imaging 
sensors  may  be  used  with  the  Laser  Sangef inder/Il luminator 
(LR/I)  transmitting  single  shot  to  generate  fire  control 
solutions  while  remaining  covert. 

e.  For  Laser  Guided  Ordnance  ( LGO )  engagements 
SEAFIRE  will,  as  a  minimum,  provide  laser  target 
illumination  during  the  actual  guidance  time  of  the  LGO.  To 
minimize  operator  workload  during  this  critical  period  of  an 
engagement,  SEAFIRE  should  be  optimized  for  automatic  target 
tracking . 

C.  REQUEST  FOR  PROPOSAL 

As  previously  mentioned,  a  Request  for  Proposal  (RFP) 
was  released  to  industry  for  design  and  support  of  SEAFIP.E. 
The  contractor's  response  required  not  only  a  firm  system 
design  but  also  lata  substantiating  his  awareness  of  and 
implementation  experience  in  production  and  life  cycle 
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support  of  major  weapons  systems.  The  following  is  a  list  of 
volumes  included  in  the  contractor's  proposal: 


1.  Prime  Item  Development  Specification 

2.  Interface  Definitions 

3.  Master  Test  Plan 

4.  Substantiating  Technical  Data 

5.  System  Project  Management 

6.  Training 

?.  Support  and  Test  Equipment  Plan 

8.  Contractor  Furnished  Spares  and  Repair  Parts 

9.  Producibility  Engineering  and  Planning 

10.  Technical  Manual  Organizational  Plan 

11.  LAMPS  Electro-Optical  POD  Engineering  Considerations 

12.  Cost  Data 

The  above  list  depicts  the  depth  of  design/support 
detail  required  of  the  contractor  and  are  only  mentioned  to 
provide  a  top  level  view  of  the  information  used  by  the  O.S. 
Navy  evaluation  team. 

1.  .Mlcronr ocessors/Flrmware  Requirements 

The  SEAFIRE  computer  (see  Figure  1)  is  an  integral 
subsystem  which  provides  for  processing  of  all  data 
necessary  for  the  functioning  of  the  system.  The  word 
computer  is  a  misleading  term  because  it  connotates  a  single 
item.  Although  the  SEAFIRE  contractor  was  provided  an 
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AN /UTS-20  computer  set  with  peripheral  equipment  for  use 
during  system  development  and  check-out,  in  actuality  he  was 
not  prohibited  from  using  additional  imbedded  processors  to 
support/enhance  the  AN/UYK-20  processing  capabilities. 
Specifically  the  use  of  microprocessors  was  encouraged. 


SEAFIRE 


The  RFP  stated  that  microprocessors  introduced  in 
would  be  selected  based  oa  performance. 


logistic/maintenance  support,  ease  of  programming  and  cost. 
Additionally,  microprocessor  architecture  would  have  to  be 
designed  to  emulate  a  subset  of  the  AN/UYK-20  computer 
instruction  repertoire  such  that  presently  available  Navy 
development  software  (e.g.  CMS-2  compiler,  assemble  debug 
tools,  data  retrieval,  data  reduction,  etc.)  could  be  used 
to  minimize  development/1  if e  cycle  support  risk  and  cost.  At 
least  a  20  percent  memory  reserve  and  a  35  perqent 
processing  time  reserve  applies  to  each  processor.  In 
addition,  the  firmware  development/documentation/testing  and 
review  would  be  treated  the  same  as  the  software  development 
documentation/testing  phases.  Firmware  is  defined  as  all 
software  that  is  not  resident  in  the  AN/UYK-20  and  is 
necessary  for  the  operation  of  SEAFIHE.  This  includes  all 
programs  developed  for  microprocessors,  microcomputers,  and 
microcontrollers.  The  microprocessors  were  also  to  be 
designed  such  that  effort  required  to  change  the  program  for 
an  inservice  SEAFIRE  would  be  minimized. 

Based  on  the  above  description  in  the  RFP,  each 
contractor  team  responded  with  a  distincly  different 
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computer  architecture  for  SEAFIRE.  Due  to  this  fact  and 
others  as  stated  before,  the  evaluation  of  varying  computer 
architectures  on  the  same  strict  performance  factors 
presented  a  difficult  problem  and  did  not  necessarily  result 
in  the  "best"  computer  architecture  selection.  Be  that  as  it 
may,  the  design  presented  in  the  next  section  is  the 
evaluation  object  for  this  thesis  and  it  is  hoped  that  as  a 
result  of  the  performance  evaluation,  specific  proposals  can 
be  suggested  which  may  provide  possible  system  enhancements. 

D.  PROPOSED  CONTRACTOR  SYSTEM  DESIGN 

1 .  System  description 

SEATIRE ,  as  described  by  the  system  contractor 
(21), is  an  Electro  -  Optical  Fire  Control  Subsystem  (EOFCS) 
modular  addition  to  existing  shipboard  Gun  Fire  Control 
Systems  (GFCS)  Mk  86,  Mk  68,  and  Mk  92.  This  addition  allows 
those  functions  previously  defined. 

The  modular  design  of  SEAFIRE  permits  it  to  be 
configured  as  an  independent  GFCS  for  application  onboard 
ships  on  which  there  is  no  other  GFCS.  (  See  Figure  2)  As  an 
independent  GFCS,  SEAFIRE  can  perform  the  functions  listed 
above  and  all  functions  neccessary  to  engage  and  direct 
gunfire  against  all  trackable  surface  targets,  including 
direct  acceptance  of  tactical  information,  interface  with 
own  ship  sensors,  generation  of  gun  laying  orders,  and 
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interface  with  gun  mounts. 

2 .  General  Description 

SEAFIRE  comprises  two  primary  equipment  groups, 
which  are  implemented  in  accordance  with  the  Standard 
Electronic  Module  (SEM)  program: 

a)  The  above  deck  equipment,  consisting  of  the  EO 
director.  The  EO  director  includes  an  enclosed  turret,  which 
is  mounted  on  the  outer  gimbals  of  the  SEAFIRE  pedestal.  The 
turret  enclosure  is  designed  to  house  the  Television  Sensor 
(TVS),  Thermal  Imaging  Sensor  (TIS)  and  Laser  Rangefinder/ 
Illuminator  (LR/I).  The  turret  is  temperature-controlled  to 
optimize  sensor  performance. 

b)  The  below  deck  eauipment,  consisting  of  the  Below 
Deck  Processor  (BDP),  Pedestal  Electronic  Cabinet  (PEC), 
Environmental  Control  System  (ECS),  Power  Converter  Unit 
(PCU),  three  remote  video  displays,  and  a  console. 

A  common  SEAFIRE  interface  allows  integration  with 
host  or  independent  GFCS  without  hardware  or  software 
modifications.  The  console  for  the  independent  GFCS  includes 
the  processing  for  gun  order  generation  and  interface  with 
own  ship  systems.  This  impacts  only  the  external  interface 
to  the  applicable  ship  and  not  the  basic  SEAFIRE  interface 
design . 

System  processing  is  performed  in  the  AN/UYK-20 
computer  programmed  in  the  CMS-2  language.  Computer  program 
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components  are  required  to  implement  the  following 
functions:  Executive,  Input/Output,  Control,  Displays, 

Director  Control,  Target  Motion  Analysis,  Fault 
Isolation/Detection,  and  Data  Extraction.  The  program  is 
constructed  in  modules,  with  each  module  structured  to 
perform  one  of  the  processing  functions.  The  multit’-.ie  of 
functions  that  must  he  performed  within  the  system  are 
interfaced  and  monitored  for  correctness  hy  the  3DP 
Interface  Controller,  which  also  performs  the  core 
activities  associated  with  fault  detection  and  location. 

As  previously  mentioned,  the  contractors'  use  of 
microprocessors  was  encouraged  hy  the  U.S.  Navy.  The 
contractor  has  chosen  to  implement  microprocessor  technology 
in  the  BDP  unit.  Specifically,  microprocessors  or 
microcontrollers  are  implemented  in  the  following  units  of 
the  BDP: 

a)  Interface  Controller  (IFC) 
h)  Automatic  Video  Tracker  (AVT) 
c)  Data  Director  (DD) 

It  was  originally  intended  to  perform  the  analysis 
in  this  thesis  on  algorithms  running  on  the  microprocessor 
architecture.  But  since  much  of  the  architectures'  software 
and  hardware  is  still  in  the  process  of  design  and  the  fact 
that  several  areas  may  currently  he  proprietary  to  a 
contractor  or  subcontractor,  these  architectures  were  not 
evaluated.  The  particular  facet  of  the  system  evaluated 
(AN/UTI-20  Computer  Program  Components)  will  he  explained  in 
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a  later  section. 


3.  AN/UYK-20  Functional  Description 

This  section  provides  an  overview  of  the  software 
functional  Computer  Program  Configuration  Item  (CPCI)  and 
its  included  Computer  Program  Components  (CPCs).  The 
software  architecture  and  interface  are  also  described.  The 
SEAFIRE  computer  serves  as  the  controlling  center  of  the 
SEAFIRE  system,  receiving  data  from  its  separate  components, 
and  routing  information  to  those  components  reouiring  data 
from  other  sources  (see  figure  3  ). 

The  SEAFIRE  Interface  will  provide  the  SEAFIRE 
Computer  with  the  means  to  communicate  with  all  of  the 
SEAFIRE  hardware  components,  collecting  data  from  each 
component  and  transferring  these  data  to  the  SEAFIRE 
Computer  in  a  single  block.  Similarly,  the  SEAFIRE  Interface 
will  receive  outputs  from  the  SEAFIRE  Computer  and 
distribute  these  data  among  the  SEAFIRE  hardware  components. 
To  the  SEAFIRE  Computer,  all  of  the  SEAFIRE  hardware 
components  appear  to  be  a  single  device,  because  a  single 
block  transfer  is  performed  for  both  input  and  output. 
Furthermore,  a  single  input  interrupt  and  single  output 
interrupt  is  involved.  Due  to  the  appearance  of  a  single 
input/output  device  relative  to  the  SEAFIRE  Computer,  the 
software  is  discussed  in  terms  of  the  SEAFIRE  Interface  (ie, 
same  as  Interface  Controller  or  Below  Deck  Processor). 
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SEAFIRE  HARDWARE  COMPONENT  BLOCK  DIAGRAM 
Figure  3 


The  host  GFCS  Operator  will  be  able  to  control  and 
monitor  the  SEAFIRE  System  at  the  Weapon  Control  Console 
(WCC).  The  WCC  is  upgraded  to  include  a  SEAFIRE  Control 
Panel  for  control,  and  a  shared  Video  Display  for 
monitoring.  The  Television  Sensor  (TVS)  or  Thermal  Imaging 
Sensor  (TIS),  used  with  the  AVT,  and  director  position 
readouts  will  provide  the  SEAFIRE  Computer  information 
neccessary  to  determine  target  azimuth  and  elevation.  The 
Laser  Rangef inder/Illuminator  (LR/I)  will  provide  the  range 
to  the  target.  Using  information  from  these  sources,  the 
SEAFIRE  Computer  will  be  capable  of  outputting  target 
position,  velocity,  and  acceleration  to  the  GFCS  for 
engaging  the  target.  The  optically  aligned  TVS,  TIS,  and 
LR/I  common  optical  pointing  will  be  controlled  by  a  single 
azimuth  and  elevation  rate  command  from  the  SEAFIRE  Computer 
(see  figure  4) . 

The  target  image  data  received  by  the  TVS  and  TIS 
will  be  sent  to  the  AVT,  where  the  target  position  Is 
calculated.  The  AVT  will  determine  target  position  relative 
to  the  upper  left  corner  of  the  video  raster  and  send  the 
target  relative  position  data  to  the  SEAFIRE  Computer  at  a 
6P  Hz  rate. 

AVT  data  may  come  from  either  the  TVS  or  TIS,  but 
not  simultaneously.  The  data  source  is  specified  by  the 
operator  at  the  SEAFIRE  Control  Panel.  Additional  options 
are  available  at  the  SEAFIRE  Control  Panel  that  affect  the 
data  flow  from  the  TVS/TIS  to  the  AVT  and  actual  processing 


SEAFIRE  HARDWARE  COMPONENT  DATA  FLOW  DIAGRAM 

Figure  4 


within  the  AVT,  embedded  microprocessor.  The  operator  may 
select  one  of  up  to  six  filters  to  modify  the  video  input  at 
the  TVS/TIS.  For  the  TIS  only,  he  may  control  the  Gain, 
Bias,  and  select  either  Black  or  White  track.  Tor  the 
TVS/TIS  he  may  control  video  Enhancement,  Focus,  and  select 
either  Wide  Field  Cf  View  (VFOV)  or  Narrow  Field  Of  View 
(NFOV ) .  At  the  AVT,  he  may  select  either  Scene  or  Point 
digital  tracking. 

The  SEAFIRE  Computer  will  pass  the  target  position 
through  a  Kalman  Filter?  (1)  to  smooth  the  target  position 
to  a  steady  state,  (2)  to  calculate  target  position, 
velocity,  and  acceleration  and  (3)  to  predict  where  the 
target  will  be  in  the  next  update  cycle.  The  SEAFIRE 
Computer  will  then  output  target  position,  velocity  and 
acceleration  via  NTDS  Slow  Interface,  to  the  GFCS,  so  that 
the  GFCS  can  compute  a  ballistic  solution.  The  data  input 
and  output  over  the  NTDS  Slow  Interface  will  be  identical 
for  the  four  configurations  of  the  SEAFIRE  System  (Mk  86,  Mk 
68,  Mk  92  and  Standalone)?  therefore,  only  one  version  of 
the  computer  program  need  be  maintained.  The  development  and 
maintenance  of  only  one  computer  program  reduces  costs  and 
accents  software  commonality.  The  SEAFIRE  Computer  also  will 
output  commands  to  move  the  Director  so  that  the  target  will 
remain  in  the  TVS/TIS  FOV. 

The  SEAFIRE  Computer  contains  one  Computer  Program 
Configuration  Item  (CPCI)?  the  Operational  CPCI.  The 
Operational  CPCI  is  used  as  a  GFCS  to  provide  target 
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tracking  and  engagement  and  to  maintain  the  SEAFIRE  system 
in  a  state  of  operational  readiness.  The  Operational  CPCI 
performs  eight  major  functions: 


a)  Executive 

h)  Input/Output 

c)  Control 

d)  Display 

e)  Tracking 

f)  Director 

g)  Fault  Isolation/Detection 

h)  Data  Extraction 

The  CPCs  listed  below  perform  the  eight  major 
functions  of  the  Operational  CPCI: 
a)  Executive 

h)  SEAFIRE  Input  Interrupt 

c)  SEAFIPE  Output  Interrupt 

d)  NTDS  Slow  Input  Interrupt 

e)  NTDS  Slow  Output  Interrupt 

f)  NTDS  Fast  Input  Interrupt 

g)  NTDS  Fast  Output  Interrupt 

h)  Control  Panel  Input 

i)  Control  Panel  Processor 

j)  Director 

k)  Designation 

l)  Target  Motion  Analysis 

m)  Alphanumeric  Display 

n)  Symbology  Display 
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o)  Built  In  Test 

p)  Performance  Monitoring 

g)  Data  Extraction 

r)  Clock  Synchronization 

The  functions  allocated  to  each  will  not  he  described 
in  detail.  The  data  flow  between  each  of  the  above  CPC 
functions  is  shown  in  Figure  5.  As  can  be  seen  Target  Motion 
Analysis  (TMA)  it  is  a  major  central  function  to  the  system 
as  it  includes  I/O  to  several  other  key  functions.  A 
description  of  the  TMA  is  delineated  in  the  next  section. 

4.  Target  Motion  Analysis  (TMA) 

The  TMA  CPC  is  called  by  the  Executive  CPC  at  a  4  Hz 
rate  to  compute  target  position,  speed,  and  acceleration  for 
output  to  the  GFCS  and  to  the  Display  CPC.  Executive  rate 
will  be  4  Hz  since  GFCS  outputs  are  required  at  this  rate. 
The  TMA  CPC  will  use  the  AVT  reported  target  position 
relative  to  the  raster  upper  left  corner  position,  Boresight 
Offset,  Sensor  Type,  and  Director  Azimuth  and  Elevation  to 
determine  the  target  position,  velocity,  and  acceleration. 

The  Director  will  provide  inputs  neccessary  to 
determine  Sensor  Line  Of  Sight  (LOS)  in  terms  of  azimuth  and 
elevation,  and  the  ATT  will  provide  inputs  such  that  target 
azimuth  and  elevation  relative  to  the  LOS  can  be  obtained. 
In  manual  track,  only  the  Director  angles  are  used.  The  LR/I 
will  provide  target  range  as  the  input. 
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SEAFIRE  COMPUTER  SOFTWARE  DATA  FLOW 
Figure  5 
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The  A7T  will  report  the  target  azimuth  error  and 
elevation  error.  This  position  must  he  transformed  to  a 
position  relative  to  the  LOS,  and  must  he  adjusted  further 
for  the  effects  caused  by  Control  Panel  selections.  Finally, 
the  position  in  elements  must  he  converted  to  units  in 
degrees.  Control  Panel  selections  have  the  effects  listed  as 
follows: 

a)  The  number  of  degrees/element  is  different 
depending  on  wide  or  narrow  FOV  selection, 
h)  The  Boresight  offset  varies  as  a  function  of 
TVS  or  TIS  sensor  selection. 

c)  The  algorithm  can  he  changed,  and  therefore,  the 
target  position. 

The  TMA  CPC  will  include  the  necessary  processing 
to : 

a)  Correct  for  angle  bias,  convert  target  data 
to  the  appropriate  reference  frame,  and  correct 
for  parallax. 

h)  Prefilter  the  data  to  correct  for  timing  delays. 

c)  Perform  TMA  computations  required  to  derive 
smooth  target  state  variables  (position,  velocity, 
acceleration)  in  both  the  stabilized  Spherical 
and  Cartesian  coordinate  frames. 

d)  Perform  necessary  computations  during  coast 
conditions. 

e)  Output  track  quality  data. 

At  the  end  of  the  Kalman  filter,  maneuver  detection 
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is  performed.  The  maneuver  detection  subroutine  is  part  of 
the  TMA  CPC  but  is  not  discussed  due  to  its  classification. 

E.  SUMMARY 

Nov  that  the  system  has  been  described  and  methodologies 
have  been  discussed  in  general  for  performance  evaluation  of 
computer  systems,  the  next  logical  step  is  a  specific 
application  of  one  of  these  techniques.  The  next  section 
provides  a  description  of  the  performance  tool  that  is  to  be 
applied  in  the  evaluation  of  the  SEA7IRE  system. 
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.  US 5  OF  AN  EXISTING -COMPUTER  SYSTEM  PERFORMANCE  TOOL 

A.  INTRODUCTION 

The  methodology  to  he  used  for  the  computer  performance 
evaluation  is  the  one  designed  hy  I.  A.  Cox,  Jr.  (4).  This 
section  provides  a  summary  of  his  approach. 

'  In  his  dissertation,  Cox  described  the  development  of  a 
methodology  for  efficiently  predicting  concurrent  computer 
system  performance.  This  methodology  allows  the  estimation 
of  performance  of  an  existing  (or  conceptual)  computer 
organization  operating  on  a  linear  mathematical  algorithm. 
An  existing  program  is  taken  and  the  control  structure  of 
all  or  some  representative  kernel  of  the  code  is  expressed 
in  a  fashion  which  makes  the  potential  parallelism 
exploitable.  For  a  given  computer  system,  the  control 
structure  dictated  by  the  software  can  then  be  mapped  onto 
the  hardware  structure,  and  the  performance  predicted. 

The  key  to  this  process  is  the  representation  of  a 
kernel  program  or  one  of  the  basic  cyclic  events  as  a 
special  kind  of  Petri  Net  simular  to  a  marked,  directed 
graph.  In  the  directed  graph,  each  arc  can  be  regarded  as 
having  some  propagation  delay  which  is  dependent  upon  the 
performance  of  the  computer  system  executing  the  program.  If 
these  delays  are  fixed  and  known,  then  the  Question  of 
performance  reduces  to  a  question  about  the  minimum  period 
for  the  cyclic  behavior  of  the  marked  graph  which  represents 
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the  program. 

A  requester/server  interface  provides  for  construction 
of  a  two  graph  structure  which  allows  the  representation  of 
algorithms  and  hardware  organizations  by  separate  graph 
structures.  This  permits  each  graph  to  be  constructed  in 
such  a  manner  as  to  both  express  the  control  structure  and 
to  maintain  a  direct  and  meaningful  representation  of  the 
important  concepts  being  modeled. 

B.  DEVELOPMENT  OT  THE  DESIGN  EVALUATION  SYSTEM 

An  effective  concurrent  computer  system  design  tool  must 
consider  the  characteristics  of  both  systems  and  software  on 
a  more  conceptual  level.  Hopefully,  the  same  descriptive 
system  could  be  employed  to  describe  both  the  hardware 
organization  and  the  software  requirements.  The  design 
evaluation  system  should  provide  for  the  inclusion  of 
varying  levels  of  detail  in  some  hierarchical  manner  and 
should  provide  quantitative  results  of  concurrent  systems  in 
some  cost  effective  manner. 

Why  use  Petri-Nets  for  the  predictive  system?  A 
Petri-Net  may  be  thought  of  as  an  abstract,  formal  model  of 
Information  flow.  As  such,  it  is  possible  to  describe  not 
only  the  information  flow,  but  the  controls  and  constraints 
of  such  flow.  The  Petri-Net  graph  models  the  static 
structure  of  a  system  in  much  the  same  manner  as  a  flowchart 
models  the  structure  of  a  computer  program.  In  order  to 
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represent  the  dynamic  properties  of  the  system  to  be 
modeled,  a  Petri-Net  can  be  "executed"  to  respond  to  the 
flow  of  information  (or  the  occurrence  of  events)  in  the 
system. 

The  static  graph  of  a  Petri-Net  is  composed  of  two  types 
of  nodes,  circles  which  are  traditionally  called  places,  and 
bars  which  are  called  transitions.  These  nodes  are  connected 
by  directed  arcs  which  run  from  either  places  to  transitions 
or  from  transitions  to  places.  The  source  of  a  directed  arc 
is  referred  to  as  the  input,  while  the  terminal  node  is 
referred  to  as  the  output. 

The  dynamic  execution  of  a  Petri-Net  is  controlled  by 
the  position  and  movement  of  information,  as  represented  by 
markers  which  are  called  tokens.  Movement  of  the  tokens 
proceeds  according  to  certain  rules.  A  token  or  tokens  move 
when  a  transition  fires.  In  order  to  fire,  a  transition  must 
be  enabled,  that  is  all  of  the  places  which  are  inputs  to 
the  transition  may  fire.  When  a  transition  fires,  the  tokens 
are  removed  from  the  input  places,  and  tokens  are  placed  on 
all  output  places  of  the  transition. 

Petri-Nets  can  model  actual  parallel  processes  by 
attaching  some  significance  to  token  movement.  For  example, 
multiple  outputs  from  a  transition  create  multiple  tokens 
upon  firing,  which  could  be  interpreted  as  a  "fork” 
operation  activating  multiple  parallel  processes.  Similarly, 
the  multiple  inputs  to  a  transition  (which  must  all  be 
marked  for  the  transition  to  fire)  could  be  interpreted  as  a 


’join'*  operation  terminating  or  merging  independent  parallel 
sequences. 

In  each  case,  the  status  of  the  execution  at  a  given 
time  can  he  described  by  defining  the  status  of  the  tokens. 
This  distribution  of  tokens  in  a  marked  Petri-Net  is  called 
the  marking,  and  defines  the  state  of  the  net  for  a  given 
instant.  Figures  6  through  9  show  the  different  stages  of  a 
marked  Petri  Net  progressively  at  incremental  time  units  in 
the  system. 

As  first  formally  defined  by  Petri,  Petri-Nets  were  not 
always  deterministic.  For  the  purposes  of  performance 
evaluation,  a  small  restriction  was  made  to  eliminate 
non-determinism,  something  not  generally  sought  after  in 
either  hardware  or  software. 

Petri-Net  concurrent  control  system  models  have  many 
characteristics  which  are  desirable  in  a  concurrent  computer 
system  performance  prediction  system.  This  model  is  capable 
of  representing  both  hardware  and  software  systems  and  is 
hierarchical  in  nature.  These  characteristics  are  important 
in  the  predictive  system. 

C.  THE  PETRI  PERFORMANCE  PRECICTIVE  PACKAGE  (P4) 

The  reauirement  for  an  architectural  design  aid  existed. 
Cox  created  and  Implemented  on  an  experimental  basis,  a 
performance  prediction  system  based  on  Petri-Net  models.  The 
system,  named  P4,  standing  for  Petri  Performance  Predictive 
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Package,  is  described  below.  Major  components  of  the  P4 
system,  and  the  system's  intended  employment  are  shown 
graphically  in  figure  10.  The  model  implemented  at  NPS  does 
not  utilize  the  MAC  macro  expander  or  the  macro  library. 

The  design  of  a  new  computer  system  (or  the  modification 
of  an  existing  system)  is  usually  initiated  with  the 
realization  that  a  problem  exists  whose  solution  is  both 
important,  and  not  economically  feasible  in  some  sense.  The 
P4  system  is  Intended  to  be  used  in  cases  where  a  problem 
has  been  defined  and  a  system  architecture  is  to  be 
developed.  In  response  to  this  problem,  the  designer 
develops  a  solution  concept.  This  concept  includes  the 
algorithmic  portion  of  the  problem,  and  some  computer 
organization  which  hopefully  will  solve  the  problem  within 
the  various  constraints. 

At  this  point  the  designer  describes  this  solution 
concept  in  terms  of  the  P4  system.  A  P4  program  (P5) 
consists  of  a  discription  of  the  computer  system 
organization  and  capabilities.  As  we  will  see  later,  these 
descriptions  are  Petri-Nets,  and  in  order  to  make  use  of  the 
heirarchical  nature  of  these  nets,  and  to  express  system 
organizations  in  a  more  concise  and  convenient  manner,  a 
macroprocessor  was  included  in  the  system;  although  one  is 
not  used  in  this  thesis.  A  P4  program  can  be  either  a  "pure” 
PS  description,  or  can  make  use  of  the  macro  facility,  in 
which  case  it  is  referred  to  as  a  P5M  description.  This 
description  of  the  solution  concept  is  then 
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PROBLEM 


THE  P4  SYSTEM  OVERVIEW 
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evaluated  In  a  dynamic  sense  and  produces  an  analysis  of  the 
system's  predicted  performance. 

The  performance  predictions  are  made  on  the  basis  of  the 
execution  of  a  Petri-Net  simulator.  This  simulator  operates 
on  the  P5  description  of  the  proposed  system,  A  complete  P4 
program  which  Is  to  be  evaluated  by  the  Petri-Net  simulator 
consists  of  three  sections:  a  hardware  section,  a  software 
section  and  a  dynamic  section.  The  hardware  section  consists 
of  a  description  of  the  basic  subsystems  of  the  computer 
system  and  some  degree  of  subsystem  interconnections.  The 
network  which  represents  hardware  Is  auantified  in  terms  of 
its  operation  in  time.  The  software  section  consists  of  a 
description  of  a  Petri-Net  which  represents  the  algorithm  to 
be  executed  on  the  system.  This  net  is  quantified  in  terms 
of  the  basic  functions  which  are  to  be  required  of  the 
hardware.  The  dynamic  section  contains  certain  output 
instructions  and  specifications  of  the  Petri-Net's  initial 
conditions.  Formally,  both  the  software  section  and  the 
hardware  section  are  merely  descriptions  of  static  Petri-Net 
structures.  Performance  prediction  comes  from  the  attachment 
of  certain  significance  to  the  ,  structures  and  certain 
restrictions  on  the  movement  of  tokens  or  markers  within 
these  networks. 

The  dynamic  nature  of  Petri-nets  is  used  to  approximate 
the  actitively  of  the  proposed  computer  system  as  it 
executes  the  algorithm  of  interest.  Accordingly,  the  two 
Petri-Nets,  software  and  hardware,  can  be  viewed  in  a 
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requester/server  context.  The  software  or  algorithm  makes  a 
series  of  requests  for  the  services  of  the  computer  system. 
The  computer  system  fulfills  these  requests  according  to  the 
constraints  of  its  design. 

In  the  hardware  net,  events  roughly  represent  operations 
in  time.  A  collection  of  one  or  more  events  are  used  to 
represent  a  functional  unit  and  its  temporal  response  to  the 
hardware  control  constraints.  Token  movement  through  the 
hardware  net  represents  the  data  and  control  flow  of  the 
hardware  system.  A  simple  example  of  a  P5  hardware 
description  is  shown  in  figure  11. 

The  software  net's  events  represent  basic  requests  for 
service.  For  example,  an  event  might  represent  a  request  for 
an  integer  addition.  The  flow  of  tokens,  which  is  initiated 
by  a  single  marker  on  the  event  "BEGIN”,  represents  the 
logical  flow  of  the  algorithm.  An  example  of  the  hardware 
and  software  net  is  shown  in  figure  12. 

Once  these  two  Petri-Net  structures  have  been  defined. 


they  can  be 

executed 

together 

in  a  manner  which 

will 

simulate  the 

operation 

of 

the 

computer  system. 

The 

interaction 

of  the 

two 

nets 

is  controlled  by 

the 

*reouester/server  token  arbiter.  ’  The  network  simulation 
begins  with  the  marking  of  the  ” 3EGIN”  node  of  the  software 
net.  This  net  is  then  executed  according  to  standard  Petri 
rules.  The  arrival  of  a  token  at  a  place  in  the  net  is 
interpreted  as  a  request  for  service,  the  type  of  service 
depending  on  the  type  of  the  place.  Upon  arrival,  the 
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A  P4  EXAMPLE  (HARDWARE  FUNCTIONAL  UNIT) 


FORTRriN  PROGRAM 


A  P4  EXAMPLE  (SOFTWARE  PROGRAM) 


arbiter  is  notified  of  the  request  for  service. 

The  arbiter  removes  the  token  from  the  net,  and  allows 
the  software  net  execution  to  continue  until  such  time  as  no 
further  moves  are  possible.  At  this  time,  the  arbiter 
initializes  the  appropriate, hardware  units  which  correspond 
to  the  requests  by  marking  them  with  tokens. 


The 

hardware  net  is 

then 

executed  one 

step.  If 

any 

tokens 

reach  events 

which 

correspond  to 

completion 

of 

requested  service,  the 

arbiter 

is  notified. 

Here  again. 

the 

token  is  removed,  and  the  token  of  the  software  net  whose 
movement  caused  the  original  request  for  service  is  replaced 
by  the  arbiter.  This  cycle  is  repeated,  with  the  execution 
of  the  software  network,  followed  by  execution  of  the 
hardware  network.  A  P5  dynamic  section  and  the  P4  results  of 
the  examples  shown  in  figures  11  and  12  are  shown  in  figure 
13. 

Examples  were  tried  by  Cox  and  predicted  results  agreed 
well  with  actual  measurements  in  most  cases.  Some  cases  with 
wide  discrepancies  pointed  out  a  significant  characteristic 
of  the  P4  methodology.  Vhen  maximally  parallel 
representations  of  the  hardware  and  the  software  are 
provided  to  P4,  the  resulting  prediction  in  most 
circumstances  represents  the  "best  case"  execution  time. 
This  means  that  in  cases  where  a  system  has  been  either 
implemented  or  simulated  at  the  bit  level,  P4  predictions 
can  be  compared  with  bit  level  timings  and  used  as  an 
Indication  of  the  efficiency  of  the  assembly  code  generated 
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by  either  manual  or  automated  means. 

The  results  Cox  received  indicated  that  the  P4 
methodology  provides  not  only  a  simple  and  accurate  method 
for  predicting  computer  system  response  hut  is  economical  of 
modeling  resources  as  veil. 


D.  LIMITATIONS  OJ  THIS  APPROACH 


The  Petri-Net  is  a  concurrent  control  system  model  of 
demonstrated  power;  however,  Cox  indicated  that  it  does  have 
some  limitations,  perhaps  the  most  significant  of  which  is 
its  inability  to  represent  conditional  events.  Petri-Nets 
are  not  able  to  handle  these  conditions  as  they  are 
traditionally  designed.  Some  work  has  been  done  on 
developing  extensions  to  Petri  representations  which 
consider  this  situation  though  a  model  which  basically 
represents  data  as  tokens  is  difficult  to  extend  to  data 
value  dependent  situations. 

Cox  indicated  that  these  extensive  modifications  do  not 
appear  to  be  Justified  in  view  of  the  intended  operation  of 
the  performance  model.  In  general,  the  linear  mathematical 
models  which  drove  his  research  can  be  characterized  by  a 
single  or  at  most  a  few  main  computational  loops.  The 
performance  of  the  loop  calculation  drives  the  overall 
performance  of  the  program.  These  loops  can  be  represented 
as  linear  code,  and  their  performance  evaluated.  Using  this 
methodology,  the  conditional  path  problem  is  avoided. 
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Another  limitation  of  the  P4  approach  stems  not  so  much 
from  the  concept,  hut  from  the  realization.  Both  software 
and  hardware  must  he  described  in  terms  of  descriptions  of 
Petri-Nets.  These  descriptions  are  "programs"  which  are 
subject  to  all  of  the  problems  of  any  human  generated 
program. 

Experience  has  shown  that  the  representation  of  existing 
computer  programs  and  algorithms  as  Petri-Nets  is  usually 
straightforward.  Pew  errors  have  occurred  at  this  stage.  The 
automatic  generation  of  these  descriptions  from  a  FORTRAN  or 
other  algorithmic  language  source  may  be  possible. 

The  representation  of  hardware  structures  has  proven  a 
bit  more  complex.  The  hardware  Petri-Net  program  must 
carefully  include  all  explicit  and  implicit  limitations  to 
concurrency  which  the  system  will  impose.  This  reauires 
careful  consideration  of  each  design,  and  careful 
programming,  sometimes  by  persons  without  significant 
programming  experience.  In  hardware  systems  which  make  use 
of  variable  time  intervals  for  execution  (such  as  the  data 
dependent  nature  of  completion  signaling  devices),  some 
average  propagation  delay  must  be  substituted.  This 
complicates  somewhat  the  p± jgramming  problem  by  demanding  a 
detailed  analysis  of  some  sub-systems,  and  by  including 
"average  performance”  figures. 

There  is  one  other  property  which  should  be  mentioned. 
Currently,  there  is  considerable  discussion  of  "data  flow" 
computer  architectures.  These  are  machines  which  would  be 
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based  on  the  principle  of  executing  instructions  in  response 
to  the  arrival  of  operands  rather  than  in  response  to  some 
sequential  or  explicit  control  flow.  These  machines  are 
conceptually  important  because  programs  expressed  in  data 
flow  form  are  free  from  sequencing  constraints  other  than 
those  required  by  the  algorithm,  and  a  processor  using  data 
flow  representation  can  achieve  highly  parallel  operation. 
In  the  Petri  performance  model,  all  programs  are  expressed 
in  essentially  a  data  flow  notation.  A  Petri  performance 
prediction  as  previously  described  makes  use  of  all  the 
possible  parallelism  of  both  the  hardware  and  software,  and 
is  thus  "best  case"  in  some  sense. 

This  "best  case"  prediction  property  stems  from  the  fact 
that  when  properly  represented  in  Petri-Net  structures  the 
hardware  and  software  descriptions  describe  potential 
parallelism  on  a  global  basis.  The  mapping  of  requests  for 
service  into  actual  hardware  operations  makes  use  of  this 
global  parallelism,  and  the  limits  are  only  those  explicit 
in  either  the  hardware  or  software.  It  is  this  property  of 
the  Petri  performance  model  that  makes  it  useful  in  the 
evaluation  of  the  efficiency  of  generated  code,  arid  makes  it 
a  valuable  tool  in  investigations  of  compiler  and  language 
development  for  highly  parallel  machines. 

Cox's  initial  experience  using  the  P4  methodology  has 
shown  that  performance  predictions  based  on  dual  Petri-Net 
representations  of  hardware  and  software  structures  are 
accurate  and  efficient  in  terms  of  resources  required  to 


make  the  predictions.  Additionally,  the  system  is  easy  and 
sufficiently  general  so  as  to  permit  detailed  investigations 
of  alternative  computer  system  organizations  such  as  would 
be  expected  in  the  design  and  development  of  a  new  system 
such  as  SEA7IRE. 

E.  SUMMARY 

The  Petri  performance  model  has  some  limitations  which 
must  be  understood  before  it  can  be  properly  applied; 
however,  when  intelligently  used,  it  comes  very  close  to 
fulfilling  all  the  goals  of  an  ideal  design  tool  intended 
for  use  in  the  conceptual  development  of  concurrent  computer 
system  organizations.  The  next  section  deals  with  the  actual 
implementation  of  the  technique  described  in  this  chapter. 
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VI.  IMPLEMENT ATI  ON /EXPERIMENTAL  PROCEDURES 

A.  INTRODUCTION 

This  section  provides  a  description  of  the  hardware  and 
software  model  for  SEAFIRE  and  how  this  model  was  executed 
fcy  the  Petri-Net  simulator.  Some  of  the  detail  that  was 
required  concerning  the  actual  functioning  of  the  SEAFIRE 
software  was  not  available  and  therefore  certain  assumptions 
had  to  be  made  in  order  to  develop  these  netsworks.  The 
results  of  the  analysis  is  covered  as  a  function  of  the 
number  of  target  loops  (TMA)  generated. 

B.  A  DESCRIPTION  OF  THE  PROGRAM 

A  discussion  of  Computer  Software  Data  Flow  at  the  CPC 
level  was  provided  in  Chapter  IV  along  with  a  diagram  of  how 
the  CPCs  Interface  (Figure  5).  Since  it  was  decided  to 
perform  the  analysis  at  the  CPC  module  level,  a 
representation  of  the  hardware  function  for  each  module  is 
best  represented  as  a  time  interval  delay  as  predicted  by 
the  contractor.  Table  1  depicts  the  contractor's  timing 
estimates  for  each  module  in  the  Automatic  Track  Mode.  These 
figures  have  been  rounded  off  for  ease  of  implementation. 

Figure  14  represents  the  SEAFIRE  hardware  (Machine  Net). 
Each  execution  cycle  (D1,D3, . . . .D260)  is  utilized  for  one  or 
more  of  the  CPCs  of  Table  1.  The  interrupt  cycle  represents 
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the  first  seven  CPCs  listed.  These  interrupts  occur  at  a 
rate  of  645  per  second?  and  since  one  cycle  eauates  to  100 
usee,  one  interrupt  would  occur  approximately  every  15.5 
cycles.  The  other  calculations  are  linear  representations  of 
the  execution  time  for  each  CPC. 

Figure  15  depicts  the  test  estimate  of  how  the  software 
functions  for  SEAFIRE  in  the  Automatic  Track  Mode.  Steady 
state  was  assumed  so  that  the  designation  function  could  he 
ignored.  TMA  was  first  executed  for  a  total  of  two  target 
loops,  then  was  varied  on  additional  runs.  The  intention  was 
to  determine  the  loading  capacity  for  the  SEAFIRE  computer 
at  these  varying  stages  of  number  of  target  loops.  The  other 
routines  are  interrupt  driven  from  a  clock  and  are  depicted 
in  the  overhead  loop. 

As  previously  mentioned,  the  basic  simulator  was 
available  in  a  form  which  ran  on  a  CDC-5700  computer.  A 
large  amount  of  effort  to  modify  this  simulator  resulted  in 
the  program  of  APPENDIX  A  that  now  runs  on  a  PDP-11/50 
minicomputer  at  NPS.  Computer  printouts  of  the  resultant 
output  is  not  provided  as  it  was  felt  that  it  would  not  have 
been  of  significant  benefit  to  the  reader.  The  results  of 
the  analysis  are  discussed  in  the  next  section. 
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Computer  Program 

Time  Per 

Components 

Execution(100us) 

Rate(Hz) 

Executive 

1 

490 

SEAPIRE  Input  Interrupt 

1 

60 

SEAPIRE  Output  Interrupt 

1 

60 

NTDS  Slow  Input  Interrupt 

1 

16 

NTDS  Slow  Output  Interrupt 

1 

16 

NTDS  Past  Input  Interrupt 

1 

1 

NTDS  Past  Output  Interrupt 

1 

1 

Control  Panel  Input 

4 

60 

Control  Panel  Processor 

6 

10 

Director 

6 

60 

Designation 

70 

16 

Target  Motion  Analysis 

260 

4 

Alphanumeric  Display 

12 

60 

Symbology  Display 

20 

20 

3uilt-in  Test 

3 

60 

Continuous  Monitoring 

120 

1 

Data  Extraction 

3 

60 

Clock  Synchronizer 

1 

1 

SEAPIRE  COMPUTER  TIMING  ESTIMATE 
TOR  AUTOMATIC  TRACK  MODE 


TABLE  1 


1 


OUTLINE  OF  SEAFIRE  HARDWARE  REPRESENTATION 
Figure  14 


C.  PRESENTATION  OF  RESULTS 


Initial  results  showed  that  the  performance  of  the 
SEAFIRE  system  under  development  was  approximately  30%  helow 
design  goals.  Detailed  analysis  of  the  performance 
prediction  showed  significant  problems  in  the  methodology 
used  to  predict  the  performance.  The  multiple  cyclic  loop 
structures  that  are  present  in  the  SEAFIRE  hardware/software 
representation  present  deadlock  like  competition  for  the 
hardware  resources.  Several  times  during  processing  it  was 
evident  that  one  cyclic  loop  would  gain  "control”  of  the 
hardware  to  the  exclusion  of  all  other  processes;  this  loop 
consuming  all  hardware  resources  available.  In  a  real  time 
system,  an  Executive  routine  would  drive  the  interrupts 
based  on  a  clock.  This  reflects  a  problem  of  using  the  Pd 
system  as  it  currently  stands  to  model  real-time  (interrupt 
driven)  systems. 

Subseauent  experiments  indicated  that  the  computer 
program  flow  could  be  manipulated  in  a  cyclic  (synchronous) 
manner  to  approximate  ar.  interrupt  driven  environment. 
Although  the  results  closely  replicate  the  contractor's 
predictions  concerning  the  timing  estimates  required  for 
program  execution,  a  true  representation  of  the  real  time 
fire  control  program  was  not  created. 

It  would  also  have  been  preferred  if  the  processing  of 
the  embedded  microprocessors  could  have  been  included; 
although  it  would  have  been  rather  simple  to  implement  at 
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this  level,  the  results  would  not  have  been  significantly 
altered.  A  lower  level  of  detail  (  ie,  software  running  on 
the  actual  hardware  )  would  provide  the  expected  output  of  a 
faster,  more  efficient  fire  control  solution  which  is  less 
dependent  on  the  centralized  processor  concept. 

The  final  timing  estimates  indicate  that  the  proposed 
software  design  will  meet  the  Navy's  processing  time 
requirements  and  have  the  capacity  of  expansion  to  include 
additional  functions  as  system  development  proceeds. 

After  further  analysis,  the  structure  of  the  programs 
were  modified  so  that  a  maximum  number  of  target  loops  could 
be  accomplished  without  consideration  for  the  administrative 
functions . 


VII  . 


The  U.S.Navy 

and  DOD  are 

not 

doing  an 

adequate 

Job  of 

specifying  and 

developing 

the 

criteria 

to  be 

used  as 

standards  for  computer  system  evaluation  and  the  prediction 
of  their  performance.  The  tools  are  available,  but  yet  past 
methods  are  implemented  without  considering  innovative 
industrial  ideas.  Only  token  amounts  of  funding  are  expended 
where  the  payoff  is  the  greatest?  in  early  conceptual 
development  phases. 

Despite  the  advances  in  these  areas,  the  question  also 
arises  as  to  whether  the  DOD  can  exploit  these  ideas  with 
the  support  of  industry.  A  number  of  approaches  have  been 
actively  pursued  over  the  last  few  years,  however,  there  is 
not  currently  a  firm  direction  in  employing  these  new 
techniques  in  industry  or  DOD. 

A  new  dimension  for  the  analysis  of  computer 
architectures  has  emerged.  These  methods  can  enhance  the 
performance  of  computer  systems  and  create  an  iterative 
atmoshere  between  industry  and  DOD  which  is  required  for 
future  systems  development. 

The  methodology  presented  in  this  thesis  should  be 
considered  as  a  partial  effort  in  this  direction.  The 
approach  is  theoretically  sound  but  its  implementation 
requires  a  more  thorough  analysis  with  appropriate  tailoring 
for  i 1 5  implementation.  The  rapid  development  of  computer 
*.»rh color/  dictates  that  the  DOD  be  able  to  better  cope  with 
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this  pace.  Further  research  and  development  into  the  causes 
and  the  nature  of  the  problem  of  simulating  an  interrupt 
driven  real-time  combat  system  is  highly  recommended. 
Section  V  mentioned  that  the  P4  system  is  directly  analogous 
to  data  flow  computing  models.  If  the  problem  is  inherent  m 
the  P4  system,  it  may  very  well  be  inherent  in  data  flow 
computing  models,  which  will  inhibit  their  use  in  this  type 
of  analysis.  For  this  reason,  it  makes  further  research  in 
this  area  imperative  prior  to  other  implementations.  It  is 
recommended  that  this  and  other  methodologies  be  explored 
further  and  hopefully  utilized  in  the  near  future. 
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1 

2 

3 

9 

5 

6 

7 

8 
9 

10 

11 

IP 

13 

19 

15 

16 

17 

18 

19 

20 
21 
22 
23 
29 
25 

27 

28 

29 

30 

31 

32 

j3 

39 

35 

36 

37 

38 

39 

90 

91 

92 

93 
99 

95 

96 

97 

98 

99 

50 

51 

52 

53 
59 

55 

56 

57 

58 

59 

60 


PPOGRAM  PFTRl-NFT  REQUESTOR/SERVER  SIMULATOR 


THIS  PROGRAM  IS  TH£.  REQUESTOR/SERVER  INTERFACE 
MODEL  FOR  IMPLEMENTATION  IN  THE  P5  NETWORK. 

COMMON /NET/  NET (255, 9) , NTRNS ( 255 , 3 ) ,NFRE (999,2) , 

1  COMMON /SOFT/FJNtT (255,9) , JTRNS(255, 3) , JEV, JTR 
C 

DO  0005  1=1,255 
MET ( I , 1 ) =0 
NTRN8(T» 1 1=0 
JNFTU,  1  )  =0 
JTPNS(I,1)=0 
0005  CONTINUE 
CALL  I N I T 
C 

0010  CONTINUE 

IFl(MA?CHSf(  W5HBEGIN,5)  .EO.l  )  GO  TO  0020 
IF(MATCHS(1 ,3HEN0,3).E0.1 )  GO  TO  0090 
CALL  EPRRWR ( 1 , 7h  MAIN, 0,0) 

GU  TO  0090 
C 

0020  J  rr  H  S  (2, 7MMAChINE,  7)  .EO.  1 )  call  STATTC(NET, 

IN  T RNS , NE V , NTP ) 

IF(MATChS(2,7rlOYNAMIC,7' .FO.l  )  CALL  DYNAMO 
IF(MATCHS(2,7HPR0GPAM,7).EU.1)  CALL  PuMNET 
IF (MAI  CHS ( 1 ,3HEN 0,3). EO.l )  GO  T9 J 0  1C > 

IF (MA TCHS ( 1 , 7HMACHINE , 7) .NE.  1  .AND.  MATCHS ( 1 , 
l7hOYNAVIC,7).ME.1  _ 

1  .AND.  MATCHSl 1 ,7HPROGRAM,7) .NE. 1 )  GO  TO  0030 
GO  TO  0010 
C 

0030  CONTINUE 

CALL  fcRRRRR ( 1 , 7h  MAIN, 0,0) 

C 

0090  (NE  t  ntr,ns  , NFRE  , NXTF,KTIMF,NEV,NTR) 

CALL  DUMP (JNFt,JTRNS, NFRE, NXTF,KTIM£, JEV, JTR) 

CALL  TDUMP 
CALL  EXIT 
END 
C 
C 

COVMON/NF f /  NET (255,9) ,NTRNS(255,3) ,NFRE (999,2) , 

1NXTF,KT1ME,NEV,NTR 
COMMON/CTRLR/  TMHDF, ICQ(?50) 

CQMMON/RAND/  ranop 

c  START-UP .  DEFINE  DEVICES  FOR  OUTPUT, 

C  GET  STARf-ijP  CTPLP  MODE  AND  RANDOM  MODt  PROBABILITY 

C  FROM  TTY.  C  PE  A  Tr  A  FICTICIOUS  NODF  *  RANDOM • . 
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61 

62 

63 

69 

65 

66 
67 
6fl 

69 

70 

71 

72 

73 
79 

75 

76 

77 

78 

79 

80 
61 
82 
83 
89 

85 

86 
87 
8« 

89 

90 

91 
9? 
93 

99 

95 

96 

97 

98 

99 
100 
101 
102 
103 

109 

105 

106 

107 

108 
1  09 

110 
1  11 
112 
113 
1  19 

115 

116 
1  17 
1  18 
1  19 
120 


0PFN( UN iT=7, NAMEs 'NETOUT .LST 1 , TYPE =  ' NEW' ) 
OPFN(UN1T=5,NAMEs'DPO:NETINP.INP; 1 ’ , TYPE= 'OLD*  , 
IPEADONir ) 

0100  FORMAT  ( / »  '  NET-3IM  VER.  29*,//) 

kRITE(7, 01001 

0120  FORMAT (5X,  ' ^PROGRAM  START-UP  MODE  =  ',15, 

1'  RAND.  PROd.s  ‘,F6.3,//) 

CALL  SC AMR ( 5 ) 

CALL  XlNTGRd  ,IM0DE) 

CALL  XFLOAT(?,RANDP) 

WKITE(7,0120)  T  MODE , R ANOP 
CREATE  THE  PHONY  MODE. ..AS  NUMBER  255 
CALL  NAMEIT (NET (255# 1 ) , 6HR  ANDOM , 6 ) 

RETURN 

FNO 


SUBROUTINE  STATIC (KNET ,  K TRNS , KEV , KTR ) 

COWMON/OMP/  MFREE1 
COMMON/SCAN/  NUMB, IW0RD( 15,10) 

COMMON /ME  1 /  NET (255, 9) ,NTRNS(255, 3 ) , NFRE (999 , 2 ) , 
1MXTF ,KTIME,NEV,NTR 
01  ME  NS  TON  KNET (255,9) , K TPNS ( 255 , 3 ) 

BYTE  TEMP 

DIMENSION  TEMPflO) 

NET  DEFINITIONS 

NF  T ( N ,  1 )  S  POINTER  TO  NAMES  ARRAY  WHICH  HOLDS  NAME. 
NET  ( N , 2 )  =  marker  (0  --)  UNMARKED) 

NET(N,3)  =  RESOURCE  REQUIREMENTS  (TYPE) 

NE T ( N , 9 )  =  OUTPUT  FLAG  FOR  EXECUTION  PRINT. 

NEV  IS  NUMBER  OF  EVENTS 


NTRNS  DEFINITIONS 
NT RNS ( N , 1 )  =  NAME  OF  TRANSITION 

NTRNS (N , 2 1  =  POINTER  TO  TRANSITION  INPUTS  IN  FREE 
SPACE 

NTRNS ( N , 3 )  =  POINTER  TO  TRANSITION  OUTPUTS 
NT R  IS  NUMBER  OF  TRANSITIONS 


NFREE  OFFINITTONS 

NFRE (N, 1 )  POINTER  TO  AN  EVENT  IN  NET 

NF  RE ( N , 2 )  POINTFR  TO  NEXT  ENTRY  IN  NFRE  OR  NIL  (0). 

NX TF  IS  POINTER  TO  NEXT  FREE  SPACE. 

BEGIN  STATIC  LOOP  TABLE  BUILDING 
0200  CONTINUE 

CALL  SC  AMR ( 5 ) 

IF(MATCHS(1,3HEND,3).E0.1)  GO  TO  0291 
IF(MATCHS( 1 ,7HDECLARE,7) .NE. 1 )  GO  TO  0290 
IF(MATCHS(3,5HEVENT,5).E0.1)  GO  TO  0210 
IF (MATCHS(3, 1 OHTPANST TTOM, 10) .EQ. 1 )  GO  TO  0290 
GO  TO  0290 
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'21 

12? 

123 

12a 

125 

126 

127 

128 
129 
13ft 

131 

132 

133 
139 

135 

136 

137 
1  38 
139 

l  ao 
1  a  l 
l  42 
ia3 

144 

145 
1  46 
l  a7 
1  48 
1  49 

150 

151 

152 

153 
15a 

155 

156 

157 

158 

159 

160 
1  6  1 
162 
163 
1  &a 

165 

166 

167 

168 
169 
1  70 

171 

172 
1  73 

174 

175 
1  76 

177 

178 
1  79 
laft 


0210  CONTINUE 

CALL  JW0RD(2,TEMP) 
N£XT=IFINDN(TEMP,KNET) 
IF(NEXT.ME.O)  GO  TO  0220 
K£V=KEVtl 

TF  (KFV.GT.255)  GO  TO  0230 
CALL  NAMINP(KNE f (KFV, 1 ) ,2) 
CALL  XINTG»CNUMH,NEXT) 
KNET(KFV,3)sNEX  r 
GO  10  0200 
0220  CONTINUE 

CALL  ERRRRP ( 3  #  8h 
GO  TO  0200 
0230  CONTINUE 

CALL  ERRPRR ( 2 , 8H 


STATIC, 0,0) 


STATIC, 0,0) 


STATIC, 0,0) 


0240  CONTINUE 

CALL  JWORDT2, TEMP) 
N1=IFINDT(TEVR,KTRNS,KTR) 

IF  r i'4 1  .EQ.KTR)  GO  TO  0250 
CALL  ERRRRR ( 3 , 8H 
GO  TO  0200 
0250  CONTINUE 

CALL  SC  AMR  f  5 )  ,  , 

IF (MATCHST 1 , 3HEND, 3) .ED. 1 )  GO  TO  0200 
IF(MATCHS(1 ,5h INPUT ,  5)  .EQ.  1  )  GO  TO  0260 
IF (MATCHSl 1 ,6HOUTPUT,6) .EQ. 1 )  GO  TO  0280 
CALL  ERRPRP ( 5 , 8H  STATIC, 0,0) 

GO  TO  0250 
0260  CONTINUE 

CALL  JWORO ( NUMB , TEMP ) 

N2=IFINDM(TERP,KNET) 

TF ( N? .NE . 0 )  GO  TO  0270 

CALL  ERRPRR ( a  »  8h  S T A T IC , i WORD f NUMB , 1 ) , 0 ) 
GO  TO  0250 
0270  CONTINUE 

CALL  SETFHE(KTPNS(M1 ,2) ,N2) 

GO  TO  0250 
0280  CONTINUE 

CALL  JWOPDTNUMP, TEMP) 

M2=IFIN0N(TEvP,KNET) 

IF  (N2.EQ.O)  GO  TO  0260 
CALL  SETFRE(K TRNSTNl , 3) ,N2) 

GO  TO  0250 


0290 

0291 

0292 


CONTINUE 

CALL  ERRPRR ( 5 , 8H 
GO  TO  0200 


STATIC, 0,0) 


CONTINUE 

IF(IMFRST.NE.O)  GO  TO  02®2 

IMFRSTsl 

NFREE  1=!M<TF 

CONTINUE 

CALL  LI3TX  f KME T , K TPNS , KFPE , NX TF , K T I  ME , KE V , K TR ) 

RETURN 

END 
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181  SUBROUTINE  JWGRD (NUMBER, STRING) 

182  BYTE  IWORD 

183  COMMON/SCAM/  NUMB , I WORD ( 1 5 , 1 0  ) 

189  BYTE  STRING 

185  DIMENSION  STRING!  10) 

186  DO  0295  1=1,10 

187  0295  STRING (I)=IWORO( NUMBER , I ) 

188  D9000  FORMAT!'  JWORD : NUMBER, STRING:', 19, 2X/10A1) 

189  D  WRITE (7,9000)  NUMBER , (STRING ( I ), 1=1 , 1 0 ) 

190  RETURN 

191  END 

192  C 

193  C 

199  SUBROUTINE  SFTFRE ( IPO  1 N T , I V AL UE ) 

195  COMMON/NET/  NET ( 255 , 9 ) , NTHNS ( 255 , 3) , NFRE (999 , 2 ) , 

196  1NXTF,KTIME,imEV,NTR 

197  C 

198  C  FOR  TRANSITION  INPUTS  OR  OUTPUTS,  SET  UP  AND 

199  C  ENTER  VALUE  IN  ThE  CHAIN  POINTED  TO  BY  IPOINT. 

200  C 

201  IF(IPOINT.FQ.O)  GO  TO  0310 

202  MEXT=1P0INT 

203  C 

209  0300  CONTINUE 

205  NEXOLDsNExT 

206  NEXT=NFRE(NEXT,2) 

207  IF! NEXT. ME. 0)  GO  TO  0300 

208  C  END  OF  CHAIN 

20R  NxTF=N*TF+l 

210  IF (NXTF.GT.9Q9)  CALL  ERRRRR ( 2 , PH  SETFRE,0,0) 

211  NFRE (NE  XOLO, 2 )=NX IF 

212  NFRE(NXTF, 1 )  =  I  VALUE 

213  RETUPN 

219  0310  CONTINUE 

215  NXTF  =  NXTFM 

216  IPO  I N T  =  NX  T F 

217  NFRE(NXTF,1)=IVALUE 

218  RETURN 

219  END 

220  C 

221  C 

222  FUNCTION  I F I  NOT ( NAME , NTRNS , NTR ) 

223  BYTE  NAMF , TE  vp 

229  DIMENSION  NAVE (  1 0 ) , TEMP (  1 0 ) 

225  DIMENSION  NTRNS (255, 3) 

226  C 

22 7  C  FIND  THE  TRANSITION  'NAME'  IN  THE  TABLE  1 

228  C  RETURN  NUMbFR 

229  C 

230  D9000  FORMAT ( '  IFINDT  :  NAME , NTR • , 2X , 1 0  A  1 , 2X , 1 9 ) 

231  D  WRITE (7,9000)  ( NAMF ( I ) ,  I  =  1 ,  1  0  ) ,  NTR 

232  DO  0900  1=1,255 

233  IFIND I =1 

239  TF(NTRMS(I, D.NE.O)  CALL  GE TNAM (NTRNS ( I , 1) , TEMP ) 

235  IF (MA 1 CHC (NAVE, TFMP, 10) .FQ.  1 )  RETURN 

236  0900  CONTINUE 

237  C  DIDN'T  FIND  IT,  SO  CREATE  IT. 

238  C 

23Q  NTP  =  NrRM 

290  CALL  NAMEIT(NTRNS(NTR,1),NAME,10) 
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241 

242 

243 

244 

245 

246 

C 

247 

C 

248 

24R 

250 

251 

252 

C 

253 

C 

254 

r 

255 

C 

256 

D9000 

257 

D 

258 

25R 

?60 

261 

26  2 

0500 

263 

264 

0510 

265 

266 

267 

268 

C 

269 

C 

270 

27  t 

272 

273 

274 

D9000 

275 

D 

276 

277 

278 

0550 

27R 

280 

281 

282 

C 

283 

C 

284 

285 

286 

287 

288 

C 

289 

C 

290 

C 

291 

C 

292 

C 

293 

0600 

294 

295 

296 

297 

298 

299 

300 

C 
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TFInDT=NTR 

TF fNTR.LF.255)  RETURN 

CALL  £RRRRP(?,8H  IFTNDT,0,Q) 

return 

END 


FUNCTION  IFINDN(NAME»NET) 

BYTE  NAME ,  TEMP 

DIMENSION  MAWE ( 10) , TFMP( 10) 

DIMENSTUN  NET(255,4) 

FIND  THE  NAME  IN  THE  TABLE 
RETURN  0  IF  NOT  THERE 

FORMATT'  IFINDN:NAME  •  ,  1 0 A  t  ) 

WRTTE(7,90O0)  (NAME ( I ) , 1*1 , 10) 

IFINDNsO 
DO  0500  1=1 ,255 

IFfNETU,  D.NE.O)  CALL  GF  T  NAM  ( NET  ( 1 ,  1  ) ,  TEMP ) 

[FfMATC HC (NAME, TEMP, 10). EQ.l)  GO  TO  0510 

CONTINUE 

RETURN 

CONTINUE 

IFINON=I 

RETURN 

END 


FUNCTION  MA  TCHC ( S TRNG 1 , STRNG2, KOUNT ) 

BYTE  STRNG1 , S  TPNG2 

DIMENSION  STPNG1 f 1 0 ) , STRNG2 ( 1 0 ) 

MATCHC=0 

FORMA  r  f  '  MA  TCHC  :  ',2fl0A1,2X)) 

WRTTE (7,9000)  (STRNG1 (I) ,1=1 , 10) , CSTRNG2 Cl) , I = 1 , 1 0 ) 
DO  0550  1=1, KOUNT 

IFfSTRNGl l T )  .NE . STRNG2  f I ) )  RETURN 

CONTINUE 

MATCHC=1 

RETURN 

END 


SUBROUTINE  LTSTXfNET,NTRNS,NFRE,NXTF,KTIME,NEV,NTR) 
BYTE  TEMP 

DIMENSION  TEMP(10) 

DIMENSION  NET (255, a) ,NTRNSf 255,3) ,NFPE( 999,2) 

AFTER  STATIC  HARDWARE  NFT  IS  IN,  DO  AN  ANALYSIS, 
FIRST  PRINT  SYMBOL  TABLF  DUMPS,  THEN  DU  STATIC 
CONFLICT  ANALYSIS  OF  THE  NETWORK 

FORMAT  (//,?0X,  ' - STATIC -STRUCTURE- ANALYSIS - ' 

1//) 

WH I TF ( 7, 0600 ) 

CALL  DUMP (NET , M TRNS , NFRE , NX TF , KT TME , NEV , NTR ) 

WR  T  TE ( 7 , ObOO  ) 

RETURN 

END 


, 
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301 

302 

303 
309 

305 

306 

307 

308 

309 

310 

311 

312 

313 
319 

315 

316 

317 

318 

319 

320 

321 

322 

323 
32« 

325 

326 

327 

328 
32° 

330 

331 

332 

333 
339 

335 

336 

337 
33* 
339 

390 

391 

392 

393 
399 

395 

396 

397 

398 

399 

350 

351 

352 

353 
359 

355 

356 

357 
35* 

359 

360 


C 

C 

C 

C 


C 

C 


SUBROUTINE  DUMP (NET, NTRNS, NFRE, NX TF,KTIME,NEV,NTR) 
BYTE  TEMP 

DIMENSION  TEMP (10) 

DIMENSION  N£T(?S5,9) , NTRNS (255 , 3 ) , NFRE (999 , 2 ) 


0700  FORMAT C/,29X , 'NETWORK  ARRAY  DUMP  TIME  =  ’,15, 

1'  EVENTS  ',/,3X,'  --NAME--  -MARKER-  --TYPE ' , 

2'--  -OUTPUT-  •  ,//) 

0710  FORMAT  ( X » 10A1 ,3110) 

WRITF(7,07O0)  K  T  I  -IE 

DO  0720  1=1 ,NEV 

CALL  GFTNAM(NET( I, 1 ) , TEMP) 

WRTTE(7,0710)  ( TEMP ( T JK ) , I JK= l , 1 0 ) , (NET ( I , J ) , J=2 , 9 ) 
0720  CONTINUE 

0730  FORMAT  C/,20X,  '  TRANSITION  TABLE  AND  FREE  SPACE  DIJ* 
1MP ' » / , 3X  ,  '  --NAME--  INPUT  P  T  R  .  OUTPUT  PTR  ',//) 
0790  FORMAT (X, 10A1 ,2110) 

WRITE(7,0730) 

DO  0750  1=1, NTR 

CALL  GFTNAM(MRNS(T,  1  ),  TEMP) 

0750  WHTTE(7,0790)  f TEMP ( I JK ) , I JK = 1 , 1 0 ) , ( NTRNS ( I , J ) , 

1 J=2,3) 

RETURN 

END 


SUBROUTINE  TDUMP 

COMMON/NEI/  NET (255,9) , NTRNS C 255,3) ,NFRE (999,2), 
1NXTF ,KTImE#NEV,NTR 

COMMON /SOFT/  JNET (255,9) ,JTRNS (255,3) ,JEV,JTR 
COMMON/DMP/  NFPEE1 

COmMON/NAMF 1 /NAMESC203, 10) , N  X  T  M  A  M 

BYTE  NAMFS 

BYTE  TEMPI, TEMP2 

DIMENSTON  TEMPI ( 1 0) , TEMP?( 1 0) 

0800  FORMAT  f  X,  ' - •) 

0810  FORMAT (//, POX, 'FPEFSPACE  ',/,3X, 

l'-NUMQER-  -EVENT-  --NEXT—',//) 

0«20  FORMA  r(X,lI10,?x,10Al,1I10) 

WRITE(7,0810) 

DO  0830  1  =  1 , N  X  TF 

CALL  GETNAM(NET(NFPE(I, 1 ) , 1 ), TEMPI) 

CALL  GFTNAM( JNFT(NFRF ( I , 1 ) , 1 ) , TEMP2) 

I F ( I . LE . NFREF 1 )  WR I TE ( 7 , 0820 )  I , ( TEMP  1 ( J )  ,  J=  1  ,  1  0 ) , 
1NFPE (1,2) 

IF(I.EO.NFREEl)  WR I TF ( 7 , 0800 ) 

IF(I.GT.NFREEl)  WRITE (7, 0820)  T  ,  ( TEMP2 ( J ) , J= 1 , 1 0 ) , 
1  NFRE (I, 2) 

0830  CON  T  T NUE 

0890  FORMA T f5X, 'NAMES  MXTNAM=’,I9) 

0850  FORMA  T (5X , 1 0 A  1 ) 

WRI TE ( 7 , 0890 )  MXTNAM 
DO  0860  T=1,NXTNAM-1 
0860  WRI TF (7 , 0850)  ( N AMF S ( I , J ) , J= 1 , 1 0 ) 

RETURN 

END 


C 

C 
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361 

362 

363 
369 

365 

366 

367 

368 

369 

370 

371 

372 

373 
370 

375 

376 

377 

378 
370 

380 

381 

382 
363 
380 

385 

386 

387 

388 
38° 

390 

391 

392 

393 
390 

395 

396 

397 

398 

399 
000 
001 
002 
003 
O0O 
005 
006 
007 
008 
009 
OJO 
Oil 
01? 
013 
010 
015 
016 
017 
018 
019 
42ft 


net  . 


0900 


0910 

0920 

0930 

0940 


1000 
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SUBROUTINE  DYNAMO 

COMMON/NEf/  NET (255,0) , NTRNS (255, 3 ) ,NFRE (999,2) 
1NXTF,KTIME,NEV,NTR 
COMMON /DYN 7  LOOK  1  ( 255 ) , L00K2 ( 255 ) 

COMMON/SCAN/  NUMB ,  I WORD (15*10) 

INTERPRET  DUNAMIC  COMMANDS  AND  RUN  SIMULATION 


TF(KTIME.EO.O)  K  T I M  E  =  1 


CONTINUE 
CALL  SCANKfS) 

IF  (MATCHS(  1 ,3HF.NH,3)  .EO.l  )  RETURN 
IFfMATCHSd  ,OHMAPK,0).EQ.l)  GO  TO  0920 
TFfMA  TCHS( 1 ,6H0uTPUT  ,  6 )  .EQ.  1 )  GO  TO  0930 
IF(MATChS(l,7HExECUTE,7).EQ.l)  GO  TO  0940 
CONTINUE 

CALL  ERRRRR(5,«H  DYNAMO, 0,0) 

GO  TO  0900 

CALL  MARKET 
GO  TO  0900 
CALL  SETOUT 
GO  TO  0900 
CALL  EXEQ 
GO  TO  0900 
END 


SUBROUTINE  MARKET 

COMMON /NET/  NET (255, 9) , NTRNS f 255 , 3 ) ,NFRE (999,2) 
1NXTF,KTIME,NEV,NTR 
common /SC AN/  NUMB, I  WORD (15, 10) 

BYTE  TEMP 

DIMENSION  TEMPflO) 

MARK  AN  EVENT  WITH  THE  DESIRED  VALUE 

CALL  JWORDf 2, TEMP) 

N1sIFINDN(TEmp,nFT ) 

IF  CM  1 . NE . 0 )  GO  TO  1000 

CALL  ERHRRP ( 4 , 8H  MARKET , I WORD (2 , 1 ) , 0  ) 

RETURN 

CONTINUE 

CALL  XINTGB(NUMB, IVAIUE) 

NET(N1,2)s!VALUE 

RETURN 

END 


SUBROUTINE  SETOUT 

CUMMON/NET/  NET (255,9) , NTRNS ( 255, 3) ,NFRE (999,2) 
INXTF,KT1ME,NEV,NTR 
BYTE  IWORD 

COMMOM/SCAN/  NUMB, IW0RDU5, 10) 

BYTE  TEMP 

DIMENSION  TF-WPUO) 


, 
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92 1  C  SET  OUTPUT  FLAG  ON  DESIGNATED  EVENT 

922  C 

923  CALL  JW0PD(NJJM8,TEWP) 

929  N 1  =  IF I MOM ( TEVP ,  NET ) 

925  TFTNI.NE.O)  GO  TO  1100 

926  CALL  ERRRRR(9,8h  SE TOUT , I WORD C NUMB , 1 ), 0 ) 

927  RETURN 

928  1100  CONTINUE 

929  NET(Nl,9)s1 

930  RETURN 

931  ENO 

932  C 

933  C 

939  SUBROUTINE  EXEQ 

935  COMMON/NET/  NET (255, 9 ) , NTRNS (255, 3) , NFRE (999 , 2 )  , 

936  1NXTF,KTIME,NEV,NTR 

937  COMMON/SOFT/  JNE T ( 255 , 9 ) , JTRNS ( 255 , 3 ) , JEV , JTR 

938  C 

939  C  EXECUTE  THE  REQIJES TOR/SFRVEP  NETWORK 

990  C 

991  CALL  XINTGRC2, I  TIME) 

99?  KLTMIT=KTIME*ITI«£ 

993  C 

999  1200  CON  T I NUE 

995  IF(KTIVE.GE.KLTMTT)  RETURN 

996  CALL  EXEQ1 TJN£T,JTRNS, NFRE, NXTF,JEV, JTR, 1 ,!GO, 

997  1KTIMET 

990  IF(lGG.EQ.l)  GO  TO  1200 

999  IFfKSOFT(IGO) .EQ.O)  RETURN 

950  CALL  HWGO 

951  CALL  EXEQ1 TNFT, NTRNS, NFRF , NX TF , NE V , NTR , 0 , 1GO , 

952  1KTIME) 

953  GO  TO  1200 

959  END 

955  C 

956  C 

957  SUBROUTINE  EXEQ 1 (KNET , I TRN , NFRE , K TF , TE V , ITR , TFUNC , 

958 

959  1  IFIRE, KTIME) 

960  BYTE  TEMP 

961  DIMENSION  TENP(IO) 

962  COMMOn/DYIm/  L00i\  1  (255) , LOOK 2(255) 

963  OIMENSTON  KNET ( 255, 9 ) , II RN (255 , 3 ) , NFRE ( 999 , 2 ) 

969  DIMENSTOM  KRRINT ( 255) 

965  C 

966  C  EXECUTE  THE  SPECIFIED  NETWORK  FOR  ONE  CLICK 

967  C  1FUNC  s  1  SOFTWARE  NET, 

960  C  IFUNC  =  0  HARDWARE  NET . 

969  C 

970  C  IFIRE  s  0  — )  NOTHING  FIRED  THIS  TIME 

971  C  IFIRE  =  1  ONE  OR  MORE  TRANSITIONS  FIRED. 

972  C 

973  C 

979  IFIRF=0 

975  1300  FORMAT fX, 'Times' ,19, *\' ) 

976  TFT IFUNC .EQ .  1 )  GO  TO  1310 

977  WRT1E(7, 13001  KTIME 

978  CALL  HWRAND 

979  C 

980  1310  CONTINUE 
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«81  CALL  MARK£R(L0PK1,KNFT,ITRN,NFRE,KTF,IEV,ITR) 

08?  DO  1320  1  =  1, IEV 

083  KPR  IN  T ( I ) =0 

000  1320  CON  f  TMJE 

005  C 
086 
087  C 
080  C 
009 
090 
091 
09? 

093 
090 
095  C 
096  1330  CONTINUE 

097  C  FIRING  A  TRANSITION  -  UNMARK  INPUTS,  MARK  OUTPUTS 

096  C 

090  IF IRE= 1 

500  NEXT=ITRN(I,2) 

501  1300  CONTINUE 

50?  IF(NEXT.EQ.O)  GO  TO  1350 

503  NEX0L0=NFXT 

500  NEX  r  =  NFRF(NEXT ,2) 

505  C  CHECK  IF  NO  TOKENS. .MAYBE  USED  ON  THIS  TRANSITION 

506  IF (KNET(NFRE  (NExOlD, 1 ) ,2)  .EQ.O)  GO  TO  1370 

507  C  IF  NO  MORE  TOKENS,  HAVE  TO  SACK  OUT  OF  TRANSITION 

500  KNET (NFRE l NEXOLD, 1 ) , ? ) =KNE T ( NFRE ( NEXOLD , 1 ) ,2)-l 

509  GO  TO  1300 

510  C 

511  1350  CONTINUE 
51?  C 

513  NEXT=ITRN( 1,3) 

510  1360  CONTINUE 

515  TFTNFxT.EQ.Ol  GO  TP  1390 

516  NEXOLD=NFXT 

517  NEXT=NFRF(NEXT,2) 

510  K NET (NFRE (NEX OLD, l ) , ? ) =KNET ( NF RE ( NEXOLD , 1 )  ,2)  +  l 

519  IFUFUNC.EQ.1  )  CALL  RSIN  (KNET  (NFRE  (NEXOLD,  1 ),  l ) ) 

520  IF(IFUNC.EO.O)  C«LL  PSOUT (NFRE (NFXOLD, 1 ) ) 

521  KPRIMT (NFRE (NEXOLD, 1 ) ) =  1 

522  GO  TO  1360 

523  C 

529  1370  CONTINUE 

525  C  REPLACE  SPMF.  TOKENS..  THIS  TRANSITION  IS  WIERD... 

526  TSTOPD=NEXPLn 

527  NEX  T  =  1 TRN ( I , ? ) 

520  1300  CONTINUE 

52q  IF (NEXT  .FQ.  ISTPPD)  GO  TO  1390 

530  NEXOLO=NFXT 

531  NEXT=NFRE(NEXT,2) 

532  KNFT(NFRE(NEX0LD,1),2)=KNET(NFRE(NEX0LD,1 ),2)*1 

533  GO  TO  1300 

539  C  END  OF  BAK-UP  PROCESS 

535  C 

556  1390  CONTINUE 

537  C 

530  DO  139?  J=1 ,IEV 

539  1391  FORMAT (5X, ' *****FVFNT  •  ,  1  0 A  1 ,  *  MARKED  WITH  ',1110, 

5yo  l'*****1) 


DO  1390  1=1, ITR 

CHECK  WHICH  TRANSITIONS  ARE  READY  TO  FIRE  I 
EXECUTE 

CALL  MARKER(LOOK?,KNFT, I TRN , NFRE , KTF , IE V , I TR ) 

IF (LOOK  1(1). EQ.O  .AND.  LOOK? (  I )  .EQ .  1  )  GO  TO  1390 
IF (LOOK  1 ( I) +L00K2( I )  .EQ.  0)  GO  TO  1390 
IF(L00K1(I).EU.L00K2(I))  GO  TO  1330 
CALL  E  PRRRR ( 6 , 7h  EXEQ , I TRN ( 1 ,  1  ) , 0  ) 

GO  TO  1390 
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541  CALL  GETNAM(KNET(J,  n,TEMP) 

5  42  IFCKPRTimT  (  J  3  .£0.  t  .AMO.  KNE  T  ( J  ,  4 1  .ME  .  0  ) 

543  1  WRTTF(7, 1 391)  (  TEMP (K ) , K=1 , 10 ) , KNET ( J,  2) 

544  1392  CONTINUE 

545  C 

546  TF(IFUNC.EG.O)  KT I«EsKT IME  +  1 

547  RETURN 

549  END 

549  C 

550  C 

551  SUBROUTINE  HWGO 

552  C0MM0N/NET/NET(2S5,4),MTRNS(255,3),NFRE(999,2) , 

553  1MXTF,KTIME#NEV,NTR 

554  COMMON/CTRLR/  I^ODE , ICG (250 ) , ICQPTR 

555  C 

556  C  MARK  AS  MANY  HARDWARE  UNITS  AS  DESIRED 

557  C  (ACCCORDING  TO  OUTSTANDING  Sw  REQUESTS) 

55«  C  NOT  TO  EXCEED  THE  LIMIT  OF  ' I  MODE '  . 

559  C 

5b0  C  THEM  SHIFT  UP  THE  QUEUE,  ICQ,  AND  RESET  ICQPTR 

561  C 

562  C  IF  ICQPTR  =  0  NOTHING  TO  DO,  SO  RETURN... 

563  TF ( ICQPTP.EQ.O)  RETURN 
5o4  C 

565  DO  1400  1=1 , TCQPTR 

566  NET(TC0CI),2)=NET( TCQ(T),2)tl 

567  J- T 

5b8  IFfI.EO.I MODE )  GO  TO  1410 

569  1400  CONTINUE 

570  c 

571  1410  CONTINUE 

572  C  REPACK  QUEUE 

573  DO  1420  1  =  1  ,  1 CGPT  R- J 

574  TCQ(T)=lCQf J  +  I) 

575  1420  CONTINUE 

576  ICQPTR =ICQPfR-J 

577  C 

578  RETURN 

579  END 

580  C 

581  C 

582  SUBROUTINE  HWRAND 

583  COMMON/NFT/  N'ET(?55,4) 

584  common/rand/  randp 

585  c 

586  C  CHECK  RANDOM  EVENT  AND  MARK  IT  PROBABILISTICALLY. 

587  C 

588  PROB=R AN ( 11,12) 

589  IFCPROB.LT. RANDP)  NET ( 255 , 2 > =NF T < 255 , 2 )  M 

590  RETURN 

591  END 

592  C 

593  C 

594  SUBROUTINE  MARKER ( K R A Y , NE T , NTRNS , NFRE , NXTF , NEV , NTH  ) 

595  DIMENSION  NET1255,4),NTRNS(255,3),NFPE(999,2) 

596  DIMENSION  KRAYT255) 

597  C 

598  DO  1500  1=1, NIR 

599  KR AY  f I ) =0 

600  1500  CONTINUE 
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601 

60? 

603 

609 

605 

606 

607 

608 

609 

610 
611 
61? 
613 
619 

615 

616 

617 

618 
619 
630 

631 

632 
633 
639 

635 

636 
627 

638 

639 

630 

631 
63? 
633 
639 

635 

636 

637 

638 

639 
690 
6a  1 
6a2 
693 
699 

695 

696 
69? 

698 

699 

650 

651 
65? 
653 

659 
655 
658 
657 
65w 
65Q 

660 


DO  1530  I=t, MR 
K  IsO 
K  2  =  0 

NEX  T siMTRMS  T  1 »  2  ) 

1510  CONTINUE 

TF(NEXT.FQ.O)  GO  TO  1520 

NEX0LD=NEXT 

t'EX  T =NFRF  ( Nt  X  T , 2) 

K2=«?tl 

IF  TNF  T ( NF  RE ( NEXQL  D ,  1 ) , 2)  .NE  .0)  KlsK 1  +  1 
GO  TP  1510 

1520  CONTINUE 

IFfKl.FQ.K2)  KRAY (T)=l 

’  1 530  CONTINUE 

RE  T  URN 
END 


SUBROUTINE  FGMNET 

COMMON /SOFT/  JNET (3S5,9) ,JTRNSr 255,3) , JEV, JTR 

THE  SOFTWARE  NET  BUILD  ROUTINE... 

FIRST  RENAME 

THEN  CONTINUE  REBUILDING  :  nE  NET 
CALL  STATIC(JNFT,JTRNS, JEV, JTR) 

NON  LOUK  FOP  THE  BEGIN  STATEMENT... 

IsTFTNDNf lOHRtGIN  , JNET  ) 

IFfl.NE.O)  GO  TO  1600 
CALL  ERRRRR(8,6HPGMNFT,0) 

1600  CONTINUE 

MARK  ThE  SOFTWARE  BEGIN  EVENT 
JNET(I,3)=! 

RETURN 

END 

SUBROUTINE  RSIN(NAME) 

BYTE  TEMP 

DIMENSION  TEMPC10) 

CQMMON/NET/  N£T (255,9) ,NTRNSf255, 3) , NFRE ( 9RR , 2 ) , 
1MXTF.KT1ME ,NEV ,NTR 

COMMON /SOFT/  JMET(?55,9),JTRNS(255,3),JEV,JTR 
COMMON/RST AbL/  IRS(90,3) 

THE  RF QUEST  DR /SERVEP  INTERFACE  TABLE 

IRS(M.l)  — )  POINTER  TO  NAME  OF  SOFTWARE  EVENT 
REQUESTING  SERVICE 
I RS (M , 2 )  — )  START  TIME  OF  REQUEST. 

I RS f M , 3 )  — )  HARDWARE  UNIT  NUMBER  REQUIRED. 

COMMON /CTRLR/  TMPOF, ICQ(?50) , ICQPTR 
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661 
66? 
66  3 
669 

665 

666 
667 
666 

669 

670 

671 

672 

673 
679 

675 

676 

677 

678 

679 

680 
661 
682 
683 
689 

685 

686 
687 
66« 

689 

690 

691 

692 

693 
699 

695 

696 

697 

698 

699 

700 

701 

702 

703 

709 

705 

706 

707 

708 
70° 

710 

711 

712 

713 
719 

715 

716 

717 

718 

719 

720 


COMMON  BLOCK  CTRLR  CONTAINS  INFO  REGARDING 
HARDWARE  REQUESTS,  AND  EXISTS  SO  THAT  THE  *  OF 
REQUESTS  PER  MINOR  CYCLE  CAN  LIMIT  AS  DESIRED. 
REQUESTS  STACKED  IN  ICO,  THE  QUEUE,  AND  SEPVICEO 
AS  POSSIBLE,  A  MAX  OF  I  MODE  EVERY  MINOR  CYCLE. 

FNTER  NAM£  IN  THE  TABLE,  PLACE  HW  IN  QUEUE,  ThEN 
REMOVE  SOFT  TOKEN.  (DO  NOTHING  IF  SOFTEVENT 
IS  TYPE  0  WHICH  IS  A  NULL  EVENT  FOR  PRECEDENCE) 

CALL  GETNAM(NAM£, TEMP) 

NUMBER  =  JNET(IFTNON(TFMP,.INET),3) 

I F ( NUMBER . EQ . 0 )  RETURN 

DO  1700  1=1,90 

IF(IRS(I,l).EQ.O)  GU  TO  1710 
1700  CONTINUE 

CALL  FPRRRR( 1 1 ,9HRSIN,TEMP,0) 

1710  CONTINUE 

DU  1720  J  = 1 , N E V 

IF(NET(J, 3). EQ. NUMBER)  GO  TO  1730 
1720  CONTINUE 

CALL  EPRRKP(B,9HPSTN,NAME,0) 

1730  CONTINUE 

TCQPTR=ICuP  TR  +  1 

TF  ( ICGlPTP.GT.250)  CALL  ERRRRR  (1  1  ,  1  OHRSTN  (ICQ), 0,0) 
TCQ( TCQPTR)=J 
J  =  T  F I  NON ( TFMP , JNE  T  ) 

JNFT ( J , 2 ) =0 
I RS ( T , 1 JsNAME 
IRS(I,?)=KTIME 
IRS(I,3) =NUMP£P 

1740  FORMA r (SX, * *PKOGRAM  EVENT  ',10A1,'  REQUESTS  Hw  ' , 

1'  SVCS  ’,115) 

WR I TF ( 7 , 1 790)  (TEMP(K) ,K=1 , 10) ,KTI«E 

RETURN 

ENn 


SUBROUTINE  RSOUT (NUMBER) 
byte  TEMP 

DIMENSION  TEMP (10) 

COMMON/NET/  NET  (255, 9)  ,NTRNS(255, 3)  ,NFRE  (9<>9,2) , 
1NXTF , K  T 1 Mt , NF  V , NTR 

COMMON/SDFT/  JNE T (255,9) , JTRNS( 255,3) , JEV, JTR 
COMMON/RST AbL/  IRS(90,3) 

NET  TRANSITION  NUMBER  (HARDWARE)  HAS  COMPLETED, 

SEE  IE  TTS  TYPE  IS  .LT.  0  (A  UNIT  FTNISH  EVENT), 
AND  IF  SO,  SEE  IF  A  SOFTWARE  EVENT  WAS  EXECUTING. 
IF  SO,  ON  A  FTFO  BASIS,  COMiPLETF  THE  SOFTEVENT, 
PPINT  A  MESSAGE,  REPLACF  THF  TOKEN  IN  THE  SOFTNET 
AMD  CONTINUE. 

IF (NET {NUMBER, 3) .GE.P)  RF  TURN 

1800  FCPMAT (5X, • ^PROGRAM  EVENT  ',10*1, *  COMPLETES  *,115) 
J  =  0 

K  =  1  0000 


95 


AD” A 081  607 
UNCLASSIFIED 


NAVAL  POSTGRADUATE  SCHOOL  MONTEREY  CA  F/S  19/5 

COMPUTER  ARCHITECTURE  PERFORMANCE  PREDICTION  FOR  NAVAL  FIRE  CON”-ETC<Ul 
DEC  79  0  M  STOWERS 

NPS52-79-006  NL 


oetrin«t.ftr>  Paae  13  Tue  Nov  27  06:18:55  1979 

7  i  f 


C 

C 


721 

722 

723 

724 

725 

726 

727 

728 

729 

730 

731 
73? 
733 
73« 

735 

736 

737 
73« 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

m 
m 

755 

756 

757 

758 
75° 

760  C 

761  ' 

762 

763 

764 

765 

766 

767 

768 

769 

770 

771 

772 

773 

774 

775 

776 

777 
77* 
77° 
760 


00  1*10  1=1,90 

IF(IPS(I,3).NE.(NET(NUM0FR,3)*-1)) 

IF ( IRS ( I , 2 ) .Gt.K)  60  TO  1610 
J  =  T 

K=IRS(I,2) 

1810  CONTINUE 

IF(J.EQ.O)  RETURN 

FOUND  IT  . 

MARK  SOFTEVENT,  UNMARK  HARDEVENT 
CALL  6FTNAV( IRS(J, 1 ) , TEMP) 

K  =  TFINON(TEMP,  JNED 
CALL  GETNA'M  JNFT (K , 1) , TEMP) 

NR  T  TE ( 7,  !800)  (  TEMP  ( L  )  ,  L=  1 ,  1  0  )  ,  K  T  IMfc 
JNET(K,2)=1 

NET (NUMBER , 2 ) =N£T (NUMBER , 2) - 1 
IRS ( J , 1 )=0 
IRS ( J, 2) =0 
IKS(J,3)=0 

return 

END 


GO  TO  1810 


C 

C 

C 

C 

C 

C 


FUNCTION  KSUFT (I^UVMY) 

COMMPN/RS7 AHL/  IRS (90 , 3 ) 

COUNT  NUMBER  OF  ACTIVE  PROCESSES  IN  TABLE 

J  =  0 

DO  1900  1=1,90 
TFdRSfl,  1)  .NE.O)  JsJ+1 
1900  CONTINUE 
K  S  0  F  T  =  J 
RETURN 
END 

SUBROUTINE  NAMFIT( I POINT, STRING, KOUNT ) 

ENTER  MAMF  OF  EVENT  OR  TRANSITION  'STRING' 
INTO  THE  GENERAL  NAME  TABLE.  RETURN  A 
POINTER  TO  ITS  ENTRY  'IPOINT'. 

BYTE  NAMES, STRING, TBLANK 
COMMON /NAME1 /NAMES (20 3, 10) ,NXTNAM 
DIMENSION  STRING! 10) 

OATA  NYTNAM/1/ 

DATA  IPLANK/1H  / 

ERASE  THE  ENTRY 
DO  1920  1=1,10 

1920  NAME8(NXTNAM,I)=T BLANK 

COPY  IN  THE  DATA 
DO  1921  1=1, KOUNT 

1921  NAMES ( NX TN AM, 1 )=STRING( I ) 

BUMP  THE  POINTER  AND  TEST  FOR  OVERFLOW. 
IPOIMT=NXINAM 
NXTNAMrNXTNAMfJ 
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IF(NXTNAM.GT.203)  GO  TO  1922 
09000  FOPPAK*  NAMF1T:  IPOTNT, STRING  *  ,14, 2X,  1 A 1 0  J 
0  WRITE(7,9000)  IPO  INT ,( STRING (I ), 1  =  1 , 1 0 ) 

RETURN 

C  GOT  A  PROBLEM . 

19 2?  CONTINUE 

1923  FORMAT ( •  **NAMF  TABLE  OVFRFLOW  DETECTED  BY*, 
1’  NAME  IT.  (FATAL)') 

WRITE16, 1923) 

CALL  EXIT 
END 


SUBROUTINE  GE TN AM ( T POINT, STRING) 

GET  THE  NAME  (10  BYTE  STRING)  POINTED  TO  BY 
"IPO INT"  AND  RETURN  IT  IN  "STRING" 

BYTE  NAMES. STRING 

COMMON /NAME  1 /NAMES (20 3,  10) ,NXTNAM 
DIMENSION  STRING(IO) 

DO  1040  T=l,10 
STRING(I)=NAVES(TPOINT,I) 

FORMAT!'  GETNAM;  IPO T NT . STRING  '  ,  1 4 , 2X , 1 A  1 0 ) 
WRITE (7, 9000)  IPO  INT, (STRING! I ), 1  =  1 , 10) 

WASN'T  THAT  SIMPIE? 

RETURN 

END 

SUBROUTINE  NAM I NP ( IPO INT , NUMB ) 

NAMEIT  FROM  AN  INPUT  SCANNER  WORD 
BYTE  IWORO 

COMMON /SCAN/NUMUER, IWOPD( 15, 10) 

BYTE  TEMP 

DIMENSION  TEMP (10) 

DO  I960  1=1,10 

TEMP ( I ) =IrtORO (NUMO, I ) 

FORMA T ( '  NAMTNP:  NUMB, STRING  ' , 1 4 , 2X , 1  A  1 0 ) 
WRITE (7, 9000)  NUMB, (TEMP (I), 1=1 ,10) 

CALL  NAMEIT (TPOINI , TEMP, 1 0) 

RETURN 

END 


1940 

D9000 

D 

C 

C 

C 


I960 

C 

09000 

D 


SUBROUTINE  SCANR(LUNIT) 


FREE  FORMAT  INPUT  POUTINE.  READS  AN  BO  BYTE 
RECORD  FROM  LOGICAL  UNIT  "LUNIT"  AND  STORES  UP 
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C 

C 

C 

C 

c 

c 

c 

c 


c 

c 

c 

c 


8a  1 

842 

843 

844 

845 

846 

847 

848 

849 

850 

851 

852 

853 

854 

855 

856 

857 

858 

859 

860 
861 
862 

863 

864 
8t>5 
866 

867 

868 
8t>9 

870 

871 

872  C 

873 

874 

875  C 

876 

877  C 

878 

879 

880 
881 
882 

883  C 

884 

885 

886 

887 

888 

889 

890  C 

891 

892  C 

893 

894 

895  C 

896 

897  C 

898  C 

899 

900 


Paae  15 

TO  15  BLANK  DELIMITED  TOKENS  CLEFT  ADJUSTED) 

IN  BYTE  ARRAY  HIWO»DM. 

NUMERICAL  VALUES  CAN  BE  REFORMATTED  FROM  BYTE 
STRINGS  INTO  INTFGFR  ANO  FLOATING  POINT  VALUES 
THRU  THE  SUBROUTINES  "XFLOAT"  AND  "XINTGR". 


BYTE  INORD, ISC, 1RLANK 

COMMON /SC AN /NUMBER » I WORD f 15, 10) 

BYTE  NPUFFR 

COMMON /SC AN  1 /NPUFFR(RO) 

DATA  1 8 C / 1 H ; / 

DATA  IBLANK/1H  / 

DATA  NEOF/O/ 

DATA  KLINE/O/ 

2001  KLTNE=KLINE+t 
2000  FORMA  T  f  BOA  1 ) 

BEGIN  BY  RtADTNG  A  LINE  OF  80  BYTFS... 
READ(LUNIT,2000,END=2035,ERR=2035)  (NBUFFR(I), 
11=1,80) 

2002  FORMA  I (X,  114,  '  -  ',80A1) 

WRITE (7,20  02)  KL TNF , ( NBUFFR ( I ) , 1=  1 , 80  ) 

SET  POINTER  TO  FIRST  CHARACTER  IN  THE  BUFFER 
IPOINT  s  1 

NOa  PROCtSS  THE  FIRST  15  TOKENS  DELIML  TED  BY 
EITHER  A  BLANK  TOR  MULTIPLE  BLANKS)  OR  A 
SEMICOLON. 

DO  2025  NUMBER=1 ,15 
IFLAG=0 

SET  IWOROCNUMBER, * ) = IRL ANK ( SET  WORD  TO  ALL  BLANKS) 
DO  2005  1=1,10 
2005  I rtORDC NUMBER, I)=TBLANK 

STAPT  SCAN  OF  LINE  FROM  POINTER  ON,  FIND  NON-BLANK 
K0UNT=1 

"KuUNT "  KEEPS  TRACK  OF  NO.  OF  CHAR.  IN  THE  TOKEN 
DO  2015  KPOINT=IPOINT,80 

IFfNBUFFR (KPOINT) .ME. IBLANK  .ANO.  NBUFFR(KPOINT) 
l.NE.ISC)  GO  TO  2010 
IFf IFLAG.ED.O)  GO  TO  2015 
TFC1FLAG.ED.1 )  GO  TO  2020 

GOT  SOMETHING,  SO  PROCESS  IT.... 

2010  CONTINUE 
IFLAG=1 

I  WORD  (  NUMBER,  KOUNT)=A'BMFFRf  KPOINT) 

KOUNTsKOUNT+1 

TF(KOUNT.GT.lO)  GO  TO  2020 
2015  CONTINUE 

2020  CONTINUE 

END  OF  TOKEN  FOUND,  RESET  SOME  POINTERS 
IPOINT sKPOT NT +1 
IFf IPOINT. GT. 80)  GO  TO  2030 

2025  CONTINUE 

END  OF  8ASIC  TOKFN  GETTING  LOOP 

2030  NUMbFR=NUMBER-1 

IF  f NUMBER. EO.O)  Gu  TP  2001 
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901 

902 

903 
909 

905 

906 

907 

908 

909 

910 

911 

912 

913 
919 

915 

916 

917 

918 

919 

920 

921 

922 

923 
929 

925 

926 

927 

928 

929 

930 

931 

932 

933 
939 
9  35 

936 

937 

938 

939 

940 

941 

942 

943 

944 

945 

946 

947 

948 

949 
P50 

951 

952 

953 

954 

955 

956 

957 

958 

959 

960 


IF(MATCHS(1,  'COMMENT:  ’,8).EQ.l)  GO  TO  2001 
RETURN 

2035  CONTINUE 

:  END  OF  FILE  OR  I/O  ERROR  DETECTED 

2040  FORMAT ( 1  EOF  OR  ERROR  ON  SCANNER  INPUT  FROM  UNIT 
113) 

WRI  TE(7,2040)  LUNIT 
NEOFsNEOF+1 

IF (NEOF .GE .3)  CALL  EXIT 

NUM6ER=0 

RETURN 

ENO 


SUBROUTINE  XFLOAT (NwORP,FWORD) 

CONVERT  THE  ENTRY  TN  ARRAY  IWORD  (4  NWORD)  TO 
STANDARD  FLOATING  POINT  REPRESENTATION,  RETURN 
IT  AS  "FWORO" . 

BYTE  IWORD 
COMMON /SC  AN/NUMBER#IWORD(15»10) 

BYTE  TSTRNG 
DIMENSION  TSTRNG (10) 

COPY  STRING  (TO  ALLOW  COMPILER  TO  STORE  THE  ARRAY 
HOWEVER  IT  WANTS  TO) 

DO  2045  1=1,10 

2045  TSTRNG(I)=IW0RD(MW0RD,T) 


2050 


2055 

2060 


DEFINE  THE  FORMATS: 

FORMAT ( 1F10.3) 

DO  I T  1 

DECUDEflO, 2050, TSTRNG)  FWORD 

RETURN 

END 


•  SUBROUTINE  XINTGR( NWORD, I  VALUE) 

CONVERT  THE  ENTRY  IN  "TWORD"  TO  INTEGER 
RETURN  INTFGER  "IVALUE" 

BYTE  I WORD 

COMMON /SC AN/NUMBER, I WORD ( 15, 10) 

BYTE  TSTRNG 
DIMENSION  TSTRNG(IO) 

BYTE  IBLANK 
DATA  IBLANK/1H  / 

COPY  THE  STRING  (SAME  PROBLEM  AS  ABOVE) 
DO  2055  1=1,10 
KOUWTsI 

TSTRNG(l)=TrtORD(NwORD,I) 
IF(IW0RD(NW0PD,I).EQ.IBLANK)  GO  TO  2060 
WE'VE  FOUND  THE  END  OF  THE  LINE 
CONTINUE 
CONTINUE 
KUUNT  sKOUNT - 1 
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961 
96  2 
963 

969 

965 

966 

967 
9b8 
9b9 

970 

971 

972 

973 
97« 

975 

976 

977 

978 
97° 

900 

901 

902 

903 
909 

905 

906 

907 

908 

909 

990 

991 

992 

993 
999 

995 

996 

997 

998 

999 

1000 

1001 

1002 
1003 
1009 

1005 

1006 
1007 
1000 

1009 

1010 
101  1 
1012 
1013 
1019 

1015 

1016 

1017 

1018 

1019 

1020 


2065  FORMAT (1110) 

0EC0D£(KfHm,2065,  TSTRNG)  IVALUE 

RETURN 

END 


FUNCTION  MATCHS (NUMB, STRING, NCHAR) 

THIS  FUNCTION  DETERMINES  IF  SCANNER  TOKEN 
TrtORD(NUMB)  MATCHES  THE  CHARACTERS  IN  "STRING" 
A I  least  FOR  the  FIRST  "NCHAR"  CHARACTERS. 

IF  there  IS  A  match,  IT  RETURNS  THF  INTEGER  "1 
NU  MATCH  RETURNS  "0". 

BYTE  1N0R0 

COMMON /SC AN/NUM0ER, IWORD( 15, 10) 

BYTE  STRING 
DIMENSION  STRING C 10) 

MATCHS=0 

TEST  THE  STRINGS... 
no  2070  r=1, NCHAR 

IF  f I WORD (NUMB, I) .NE. STRING (I))  RETURN 
2070  CONTINUE 

IF  YOU  GET  HERE,  THEY  WERE  THE  SAMF... 

matchs=i 

return 

END 


SUBROUTINE  £RRRRR(KIND,KALLER, NAME, MARK) 
COMMON/RRR/  MSR(ti) 

MSG(N)sFATAL  FLAG  (l--)FATAL) 

BYTE  KALLER,NAMt 

DIMENSION  KALLER(10),NAME(10) 

MSG ( 1 ) s  T 
MSG ( 2 ) = 1 
MSG ( 3 ) =0 
MSG ( 9 ) =0 
MSG(5)=0 
MSG ( 6 ) =0 
MSG(7)=0 
MSG (8 )  =  l 
MSG (9 ) s 1 
MSG( I0)s0 
MSG ( 1 1 ) *  1 
C 

2101  F0RMAT(5X, 1A2, 'ERROR  ’,112, •  DETECTED  BY  ’,10A1 
1 '  MISSING  SECT.  bFGTN  (FATAL)  ’,IA2) 

2102  F0RMAT(5X, 1A2, 'ERROR  ',112,'  DETECTED  BY  * ,  1  0 A  1 
1'  SYMBOL  TABLE  OVERFLOW  (FATAL)  ',1A2) 

2103  FORMATlSx, 1A2, 'FRRUR  ’,112. •  DETECTED  BY  *,10A1 
1'  NAME  DUPLICATION  (IGNORED)  *,1A2) 

2109  F0RMAT(5X, 1A2, 'ERROR  •,112,*  DETECTED  BY  ',10A1 
1,'  ' # 1 0 A  1 , '  UNDEFINED  ( T GNORED ) ’ , 1 A2 ) 

2105  F0RMAT(5X, l A2, 'ERROR  ',112,'  DETECTED  BY  *,10A1 


9 

9 


9 
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1021 
1 022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 
1039 

1035 

1036 

1037 

1038 

1039 

ioao 

loai 

loa2 

1043 

toaa 

loas 

1046 

1047 

1048 

1049 

1050 

1051 

1052 

1053 

1054 

1055 

1056 
t  057 

1058 

1059 

1060 
1061 
1062 

1063 

1064 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 

1073 

1074 

1075 
107b 

1077 

1078 

1079 
10P0 


1 


(IGNORED) 


2107 

2108 

2109 

2110 
2111 


112, 

,  10A1 


1A2) 


DETECTED 
,  1 A2 ) 


BY 


'  ,  1 0  A  1 ,  '  MARKED 


— SYNTAX  ERROR-- 
2106  FORMAT (SX, 1A2, 'ERROR 
’  DYNAMIC  CONFLICT 
FORMAT (SX, 1A2, '  EVENT 
1  A  2  ) 

F0RMAT(5X, 1A2, 'ERROR  ',112,'  DETECTED  BY 
NO  PEGIN  EVENT  FOUND  (SOFTNET ) ' , 1 A2) 
FORMAT(5X, 1A2, 'ERROR  ',112,'  DETECTED  BY 
NON-EX  1ST.  HW  UNIT  REQUESTED.  ',1A2) 
F0RMAT(5X, 1A2, 'ERROR  ',112,'  DETECTED  BY 

- ERROR- 1 0 HAD-CALL-TO-ER* , 1A2) 

F0RMAT(5X, 1A2, 'ERROR  ',112,'  DETECTED  BY 


1 '  R/S  TABLE  UVERFLOW 


(FATAL) 


1A2) 


KSTARs2H** 

IF(K1ND.LT.1 
IF(KIN0.EQ.1 
IF(KIND.EQ.2 
IF(KIND.£Q.3 
IF (K IND.EQ.4 
IF(K  IN0.EQ.5 
IF (K  IN0.EQ.6 
IF(KIMD.EQ.7 
IF  (KIND.EQ.P 
IF (K I ND  ,EQ  .9 
I F (K I NO . EQ  .  1 

;  THEN  KINO 

wRITE(7,2tll 
IF ( MSG (K 1  NO ) 
CALL  EXIT 

2121  CONTINUE 
WRITE! 7,2101 
IF (MSG (KINO) 
CALL  EXIT 

2122  CONTINUE 
WRITE (7. 2102 
IF(MSG(KINO) 
CALL  EX  T  T 

2123  CONTINUE 
WRITE(7,21 03 
IF (MSG (KINO) 
CALL  EXIT 

2124  CONTINUE 
WRITE  (  7, 21 04 
IF (MSG (KINO) 
CALL  EXIT 

2125  CONTINUE 
wRITE(7,2105 
IF (MSG (KINO) 
CALL  EXIT 

212b  CONTINUE 

wRI TE ( 7, 21 06 
I F (MSG (KIND) 
CALL  Fxlf 

2127  CONTINUE 
wPITt(7,2107 
IF(VSG(KINO) 
call  EXIT 

2128  CONTINUE 


)  KlwDslO 

) 

) 

) 

) 

) 

) 

) 

) 

) 

0)  GO 

5  hstar, kind, kaller, kstar 
.EQ.O)  RETURN 


OR. 

,  KIND.GT . i 

GO 

TO 

2 

121 

GO 

TO 

2 

122 

GO 

TO 

2 

123 

GO 

TO 

2 

124 

GO 

TO 

2 

125 

GO 

TO 

2 

126 

GO 

TO 

2 

127 

GO 

TO 

2 

12P 

GO 

TO 

2 

120 

TO  2130 


)  K STAR, KIND, KALLER,KSTAH 
•EQ.O)  RETURN 

)  KSTAR,KTND,KALLER,KSTAR 
.EQ.O)  RETURN 

)  KSTAR,KTND,KALLER,KSTAR 
.EQ.O)  RETURN 

)  KSIAR, KIND, KALLER, NAME, KSTAR 
.EQ.O)  RETURN 

)  KSTAR, KINO, KALLER, KSTAR 
.EQ.O)  PETUPN 

)  KSTAR, KIND, KALLER, NAME, KSTAR 
.EQ.O)  RETURN 

)  KSTAR, KALLER, MARK, KSTAR 
.EQ.O)  RETURN 


1  0  A  1 , 
’,1110, 
1  0  A 1 , 

1  0  A 1 , 

1  0  A  l  , 

1  0  A  1  , 
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JOB!  WR I TE ( 7  >  2 1  US )  KST AR , K TNf), K ALLER , KS TAR 

10B2  IF(MSGtKINU) .EQ.O)  RETURN 

10B3  CALL  EXIT 

1 08U  2129  CONTINUE  „ 

10B5  WRITEC7,210P)  hS T AR , K I  NO , K ALLER # KST AR 

10B6  IF(MSG(KIN0) .EO.O)  RETURN 

IOB7  CALL  EXH 

10BB  2130  CONTINUE 

1 0B9  WRITE(7,21 10)  KST AR , K INO , K ALLER , KST AR 

1090  IE(MSC(KINO).EQ.O)  return 

1091  CALL  EXIT 

1092  END 
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